linux.git/drivers/char/mem.c, branch v2.6.24

x86 merge fallout: uml

2007-10-29T14:41:32+00:00

Don't undef __i386__/__x86_64__ in uml anymore, make sure that (few) places
that required adjusting the ifdefs got those.

Signed-off-by: Al Viro 
Signed-off-by: Linus Torvalds

mm: bdi init hooks

2007-10-17T15:42:45+00:00

provide BDI constructor/destructor hooks

[akpm@linux-foundation.org: compile fix]
Signed-off-by: Peter Zijlstra 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

remove ZERO_PAGE

2007-10-16T16:42:53+00:00

The commit b5810039a54e5babf428e9a1e89fc1940fabff11 contains the note

  A last caveat: the ZERO_PAGE is now refcounted and managed with rmap
  (and thus mapcounted and count towards shared rss).  These writes to
  the struct page could cause excessive cacheline bouncing on big
  systems.  There are a number of ways this could be addressed if it is
  an issue.

And indeed this cacheline bouncing has shown up on large SGI systems.
There was a situation where an Altix system was essentially livelocked
tearing down ZERO_PAGE pagetables when an HPC app aborted during startup.
This situation can be avoided in userspace, but it does highlight the
potential scalability problem with refcounting ZERO_PAGE, and corner
cases where it can really hurt (we don't want the system to livelock!).

There are several broad ways to fix this problem:
1. add back some special casing to avoid refcounting ZERO_PAGE
2. per-node or per-cpu ZERO_PAGES
3. remove the ZERO_PAGE completely

I will argue for 3. The others should also fix the problem, but they
result in more complex code than does 3, with little or no real benefit
that I can see.

Why? Inserting a ZERO_PAGE for anonymous read faults appears to be a
false optimisation: if an application is performance critical, it would
not be doing many read faults of new memory, or at least it could be
expected to write to that memory soon afterwards. If cache or memory use
is critical, it should not be working with a significant number of
ZERO_PAGEs anyway (a more compact representation of zeroes should be
used).

As a sanity check -- mesuring on my desktop system, there are never many
mappings to the ZERO_PAGE (eg. 2 or 3), thus memory usage here should not
increase much without it.

When running a make -j4 kernel compile on my dual core system, there are
about 1,000 mappings to the ZERO_PAGE created per second, but about 1,000
ZERO_PAGE COW faults per second (less than 1 ZERO_PAGE mapping per second
is torn down without being COWed). So removing ZERO_PAGE will save 1,000
page faults per second when running kbuild, while keeping it only saves
less than 1 page clearing operation per second. 1 page clear is cheaper
than a thousand faults, presumably, so there isn't an obvious loss.

Neither the logical argument nor these basic tests give a guarantee of no
regressions. However, this is a reasonable opportunity to try to remove
the ZERO_PAGE from the pagefault path. If it is found to cause regressions,
we can reintroduce it and just avoid refcounting it.

The /dev/zero ZERO_PAGE usage and TLB tricks also get nuked.  I don't see
much use to them except on benchmarks.  All other users of ZERO_PAGE are
converted just to use ZERO_PAGE(0) for simplicity. We can look at
replacing them all and maybe ripping out ZERO_PAGE completely when we are
more satisfied with this solution.

Signed-off-by: Nick Piggin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus "snif" Torvalds

Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus

2007-07-10T21:48:43+00:00

* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus: (62 commits)
  [MIPS] PNX8550: Cleanup proc code.
  [MIPS] WRPPMC: Fix build.
  [MIPS] Yosemite: Fix modpost warnings.
  [MIPS] Change names of local variables to silence sparse
  [MIPS] SB1: Fix modpost warning.
  [MIPS] PNX: Fix modpost warnings.
  [MIPS] Alchemy: Fix modpost warnings.
  [MIPS] Non-FPAFF: Fix warning.
  [MIPS] DEC: Fix modpost warning.
  [MIPS] MIPSsim: Enable MIPSsim virtual network driver.
  [MIPS] Delete Ocelot 3 support.
  [MIPS] remove LASAT Networks platforms support
  [MIPS] Early check for SMTC kernel on non-MT processor
  [MIPS] Add debugfs files to show fpuemu statistics
  [MIPS] Add some debugfs files to debug unaligned accesses
  [MIPS] rbtx4938: Fix secondary PCIC and glue internal NICs
  [MIPS] tc35815: Load MAC address via platform_device
  [MIPS] Move FPU affinity code into separate file.
  [MIPS] Make ioremap() work on TX39/49 special unmapped segment
  [MIPS] rbtx4938: Update and minimize defconfig
  ...

[MIPS] Hook for platforms to define cachability of /dev/mem regions

2007-07-10T16:32:56+00:00

Signed-off-by: Ralf Baechle

splice: divorce the splice structure/function definitions from the pipe header

2007-07-10T06:04:14+00:00

We need to move even more stuff into the header so that folks can use
the splice_to_pipe() implementation instead of open-coding a lot of
pipe knowledge (see relay implementation), so move to our own header
file finally.

Signed-off-by: Jens Axboe

Make /dev/port conditional on config symbol

2007-05-08T18:15:07+00:00

Instead of having /dev/port support dependent in multiple places on a
string of preprocessor symbols, define a new configuration directive for
it.  This ensures that all four places remain consistent with each other.

Signed-off-by: Russell King 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

header cleaning: don't include smp_lock.h when not used

2007-05-08T18:15:07+00:00

Remove includes of  where it is not used/needed.
Suggested by Al Viro.

Builds cleanly on x86_64, i386, alpha, ia64, powerpc, sparc,
sparc64, and arm (all 59 defconfigs).

Signed-off-by: Randy Dunlap 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fix bogon in /dev/mem mmap'ing on nommu

2007-04-17T23:36:27+00:00

While digging through my MAP_FIXED changes, I found that rather obvious
bug in /dev/mem mmap implementation for nommu archs. get_unmapped_area()
is expected to return an address, not a pfn.

Signed-off-by: Benjamin Herrenschmidt 
Acked-By: David Howells 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Revert "[PATCH] Fix up mmap_kmem"

2007-01-22T16:53:24+00:00

This reverts commit 99a10a60ba9bedcf5d70ef81414d3e03816afa3f.

As per Hugh Dickins:

  "Nadia Derbey has reported that mmap of /dev/kmem no longer works with
   the kernel virtual address as offset, and Franck has confirmed that
   his patch came from a misunderstanding of what an offset means to
   /dev/kmem - whereas his patch description seems to say that he was
   correcting the offset on a few plaforms, there was no such problem to
   correct, and his patch was in fact changing its API on all platforms."

Suggested-by: Hugh Dickins 
Cc: Franck Bui-Huu 
Cc: Nadia Derbey 
Cc: Andi Kleen 
Cc: Arjan van de Ven 
Cc: Andrew Morton 
Signed-off-by: Linus Torvalds