- 24 Aug, 2004 40 commits
-
-
Jesse Barnes authored
I found that sn_console was missing an include and a fix if CONFIG_SMP=n. This patch fixes up the two small problems I found. Signed-off-by:
Jesse Barnes <jbarnes@sgi.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Jesse Barnes authored
People are mainly concerned with showing off their total bogomips, not per-cpu bogomips, so turn it into a KERN_DEBUG message for the benefit of systems with lots of CPUs. Signed-off-by:
-
James Morris authored
Below is an updated version of the patch which moves duplicated transaction-based file operation code into libfs. Since the last post, the patch has been through a couple of iterations with Al, who suggested a number of cleanups including locking and interface simplification. For filesystem writers, the interface is now much simpler. The simple_transaction_get() helper should be part of the file op write method. This safely obtains the transaction request data during write(), allocates a page for it and stores it there. The data is returned to the caller for potential further processing, which then makes it available for the next read() call via simple_transaction_set(). See the selinuxfs and nfsctl code for examples of use. Signed-off-by:
James Morris <jmorris@redhat.com> Signed-off-by:
-
Pawel Sikora authored
Attached patch fix/add several cpu features. refs: [1] Intel Processor Identification and the CPUID instruction Application Note 485. http://developer.intel.ru/download/design/Xeon/applnots/24161826.pdf [2] http://www.sandpile.org/ia32/cpuid.htmSigned-off-by: -
Dave Jones authored
Only print out the ESR value if it changes after enabling vector. Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Ben Leslie authored
When compiling Linux on Mac OSX I had trouble with scripts/sumversion.c. It includes <netinet/in.h> to obtain to definitions of htonl and ntohl. On Mac OSX these are found in <arpa/inet.h>. After checking the POSIX specification it appears that this is the correct place to get the definitons for these functions. (http://www.opengroup.org/onlinepubs/009695399/functions/htonl.html) Using this header also appears to work on Linux (at least with Glibc-2.3.2). It seems clearer to me to go with the POSIX standard than implementing #if __APPLE__ style macros, but if such an approach is preferred I can supply patches for that instead. A patch against 2.6.7 which change <netinet/in.h> -> <arpa/inet.h> is attached. Signed-off-by:
-
Brent Casavant authored
It appears there is a nodemask miscalculation in the get_nodes() function in mm/mempolicy.c. This bug has two effects: 1. It is impossible to specify a length 1 nodemask. 2. It is impossible to specify a nodemask containing the last node. The following patch has been confirmed to solve both problems. Signed-off-by:
Brent Casavant <bcasavan@sgi.com> Signed-off-by:
-
Michal Ludvig authored
Add a couple more accessors for xstore features. Signed-off-by:
-
Paul Jackson authored
fs/smbfs/inode.c: In function `smb_fill_super': fs/smbfs/inode.c:563: warning: comparison is always false due to limited range of data type Unfortunately, this patch uses the notorious "gcc warning suppression by obfuscation" technique. What seems to be going on is that the uid and gid convert macros in include/linux/highuid.h: #define __convert_uid(size, uid) \ (size >= sizeof(uid) ? (uid) : high2lowuid(uid)) only call high2lowuid in the case of trying to put a bigger (32 bit, say) uid/gid in a smaller (16 bit, in this case) word. Gcc is smart enough to see that the comparison in high2lowuid() macro is silly if called with a 16 bit source uid, but not smart enough to understand from the __convert_uid() logic that this is exactly the case that high2lowuid() won't be called. So replace the logical "<" operator with the bit op "&~". This obfuscates things enough to shut gcc up. Only build the half-dozen files that use SET_UID/SET_GID, on arch i386 and ia64. Only the file fs/smbfs/inode.c showed the warning, both arch's, and this patch fixed both. Untested further, past staring at the code long enough to convince myself the change has no actual affect on the code's results. Signed-off-by:Paul Jackson <pj@sgi.com> Signed-off-by:
-
Dave Jones authored
arch/i386/mach-generic/summit.c: In function `send_IPI_all': include/asm/mach-summit/mach_ipi.h:4: sorry, unimplemented: inlining failed in call to 'send_IPI_mask_sequence': function body not available arch/i386/mach-generic/summit.c:8: sorry, unimplemented: called from here make[1]: *** [arch/i386/mach-generic/summit.o] Error 1 make: *** [arch/i386/mach-generic] Error 2 arch/i386/mach-generic/bigsmp.c: In function `send_IPI_all': include/asm/mach-bigsmp/mach_ipi.h:4: sorry, unimplemented: inlining failed in call to 'send_IPI_mask_sequence': function body not available arch/i386/mach-generic/bigsmp.c:8: sorry, unimplemented: called from here make[1]: *** [arch/i386/mach-generic/bigsmp.o] Error 1 make: *** [arch/i386/mach-generic] Error 2 arch/i386/mach-generic/es7000.c: In function `send_IPI_all': include/asm/mach-es7000/mach_ipi.h:4: sorry, unimplemented: inlining failed in call to 'send_IPI_mask_sequence': function body not available arch/i386/mach-generic/es7000.c:8: sorry, unimplemented: called from here make[1]: *** [arch/i386/mach-generic/es7000.o] Error 1 make: *** [arch/i386/mach-generic] Error 2 Signed-off-by:
-
Pawel Sikora authored
This minor fix is required to proper init "APM emulation" on HP-OmniBooks. (An external patch). "APM emulation" is very useful if you want to use a tool which looks into /proc/apm for getting informations about battery charging. Signed-off-by:
-
Josh Aas authored
A patch that reduces bkl usage in do_coredump. I don't see anywhere that it is necessary except for the call to format_corename, which is controlled via sysctl (sys_sysctl holds the bkl). Also make format_corename() static. Signed-off-by:
Josh Aas <josha@sgi.com> Signed-off-by:
-
Andi Kleen authored
Fix warnings in es7000. Otherwise gcc 3.3 complains about too large integer values. Signed-off-by:
-
Neil Brown authored
This patch adds a 'raid10' module which provides features similar to both raid0 and raid1 in the one array. Various combinations of layout are supported. This code is still "experimental", but appears to work. Signed-off-by:
Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by:
-
Neil Brown authored
__bdevname now only prints major/minor number which isn't much help. So remove most calls to it from md.c, replacing those that are useful by calls to bdevname (often printing the message when the error is first detected rather than higher up the call tree). Also discard hot_generate_error which doesn't do anything useful and never has. Signed-off-by:
-
Neil Brown authored
1/ rationalise read_balance and "map" in raid1. Discard map and tidyup the interface to read_balance so it can be used instead. 2/ use offsetof rather than a caclulation to find the size of an structure with a var-length array at the end. 3/ remove some meaningless #defines 4/ use printk_ratelimit to limit reports of failed sectors being redirected. Signed-off-by:
-
Neil Brown authored
1/ Introduce "mddev->resync_max_sectors" so that an md personality can ask for resync to cover a different address range than that of a single drive. raid10 will use this. 2/ fix is_mddev_idle so that if there seem to be a negative number of events, it doesn't immediately assume activity. 3/ make "sync_io" (the count of IO sectors used for array resync) an atomic_t to avoid SMP races. 4/ Pass md_sync_acct a "block_device" rather than the containing "rdev", as the whole rdev isn't needed. Also make this an inline function. 5/ Make sure recovery gets interrupted on any error. Signed-off-by:
-
William Lee Irwin III authored
During the kernel summit, some discussion was had about the support requirements for a userspace program loader that loads executables into hugetlb on behalf of a major application (Oracle). In order to support this in a robust fashion, the cleanup of the hugetlb must be robust in the presence of disorderly termination of the programs (e.g. kill -9). Hence, the cleanup semantics are those of System V shared memory, but Linux' System V shared memory needs one critical extension for this use: executability. The following microscopic patch enables this major application to provide robust hugetlb cleanup. Signed-off-by:
-
William Lee Irwin III authored
PAE is artificially limited in terms of swapspace to the same bitsplit as ordinary i386, a 5/24 split (32 swapfiles, 64GB max swapfile size), when a 5/27 split (32 swapfiles, 512GB max swapfile size) is feasible. This patch transparently removes that limitation by using more of the space available in PAE's wider ptes for swap ptes. While this is obviously not likely to be used directly, it is important from the standpoint of strict non-overcommit, where the swapspace must be potentially usable in order to be reserved for non-overcommit. There are workloads with Committed_AS of over 256GB on ia32 PAE wanting strict non-overcommit to prevent being OOM killed. Signed-off-by:
-
Zwane Mwaikambo authored
This was broken when the mwait stuff went in since it executes after the initial idle_setup() has already selected an idle routine and overrides it with default_idle. Signed-off-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by:
Zwane Mwaikambo <zwane@linuxpower.ca> Signed-off-by:
-
Manfred Spraul authored
Michael Kerrisk found a bug in the shm accounting code: sysv shm allows to create SHMMNI+1 shared memory segments, instead of SHMMNI segments. The +1 is probably from the first shared anonymous mapping implementation that used the sysv code to implement shared anon mappings. The implementation got replaced, it's now the other way around (sysv uses the shared anon code), but the +1 remained. Signed-off-by:
Manfred Spraul <manfred@colorfullife.com> Signed-off-by:
-
Zwane Mwaikambo authored
The incorrect mask was being used when writing back to PMNC write-only-zero bits as well as only ticking the CCNT every 64 processor cycles. Tested on IOP331 and PXA270, i'm still looking for XScale1 users... Signed-off-by:
Luca Rossato <l.rossato@tiscali.it> Signed-off-by:
Zwane Mwaikambo <zwane@arm.linux.org.uk> Signed-off-by:
-
William Lee Irwin III authored
The sole remaining usage of CLONE_IDLETASK is to determine whether pid allocation should be performed in copy_process(). This patch eliminates that last branch on CLONE_IDLETASK in the normal process creation path, removes the masking of CLONE_IDLETASK from clone_flags as it's now ignored under all circumstances, and furthermore eliminates the symbol CLONE_IDLETASK entirely. From: William Lee Irwin III <wli@holomorphy.com> Fix the fork-idle consolidation. During that consolidation, the generic code was made to pass a pointer to on-stack pt_regs that had been memset() to 0. ia64, however, requires a NULL pt_regs pointer argument and dispatches on that in its copy_thread() function to do SMP trampoline-specific RSE -related setup. Passing pointers to zeroed pt_regs resulted in SMP wakeup -time deadlocks and exceptions. Signed-off-by:
-
William Lee Irwin III authored
Every arch now bears the burden of sanitizing CLONE_IDLETASK out of the clone_flags passed to do_fork() by userspace. This patch hoists the masking of CLONE_IDLETASK out of the system call entrypoints into do_fork(), and thereby removes some small overheads from do_fork(), as do_fork() may now assume that CLONE_IDLETASK has been cleared. Signed-off-by:
-
Josh Aas authored
Attached is a patch that greatly improves the speed of freeing boot memory. On ia64 machines with 2GB or more memory (I didn't test with less, but I can't imagine there being a problem), the speed improvement is about 75% for the function free_all_bootmem_core. This translates to savings on the order of 1 minute / TB of memory during boot time. That number comes from testing on a machine with 512GB, and extrapolating based on profiling of an unpatched 4TB machine. For 4 and 8 TB machines, the time spent in this function is about 1 minutes/TB, which is painful especially given that there is no indication of what is going on put to the console (this issue to possibly be addressed later). The basic idea is to free higher order pages instead of going through every single one. Also, some unnecessary atomic operations are done away with and replaced with non-atomic equivalents, and prefetching is done where it helps the most. For a more in-depth discusion of this patch, please see the linux-ia64 archives (topic is "free bootmem feedback patch"). The patch is originally Tony Luck's, and I added some further optimizations (non-atomic ops improvements and prefetching). Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Badari Pulavarty authored
The problem is, if we increase our readhead size arbitrarily (say 2M), we call mpage_readpages() with 2M and when it tries to allocated a bio enough to fit 2M it fails, then we kick it back to "confused" code - which does 4K at a time. The fix is to ask for the maxium the driver can handle. Signed-off-by:
-
Roland Dreier authored
Looks like arch/i386/kernel/doublefault.c is one place in the code that hardcodes the assumption that PAGE_OFFSET == 0xC0000000. Here's a patch that fixes that. Signed-off-by:
Roland Dreier <roland@topspin.com> Signed-off-by:
-
James Courtier-Dutton authored
Rui Sousa has been unreachable for a long time now, so I have taken over the emu10k1 project on sf.net. Signed-off-by:
-
Andrea Arcangeli authored
There's some minor bug in the d_path handling (the nfsd one may not the the correct fix, there's no failure path for it, so I just terminate the string, and the last one in the audit subsystem is just a robustness cleanup if somebody will extend d_path in the future, right now it's a noop). Signed-off-by:
-
Andrew Morton authored
Fix up the logic which decides when the caller can dip into page reserves. - If the caller has realtime scheduling policy, or if the caller cannot run direct reclaim, then allow the caller to use up to a quarter of the page reserves. - If the caller has __GFP_HIGH then allow the caller to use up to half of the page reserves. - If the caller has PF_MEMALLOC then the caller can use 100% of the page reserves. Signed-off-by:
-
Nick Piggin authored
Previously the ->protection[] logic was broken. It was difficult to follow and basically didn't use the asynch reclaim watermarks (pages_min, pages_low, pages_high) properly. Now use ->protection *only* for lower-zone protection. So the allocator now explicitly uses the ->pages_low, ->pages_min watermarks and adds ->protection on top of that, instead of trying to use ->protection for everything. Pages are allocated down to (->pages_low + ->protection), once this is reached, kswapd the background reclaim is started; after this, we can allocate down to (->pages_min + ->protection) without blocking; the memory below pages_min is reserved for __GFP_HIGH and PF_MEMALLOC allocations. kswapd attempts to reclaim memory until ->pages_high is reached. Signed-off-by:
Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by:
-
Nick Piggin authored
Slightly change the writeout watermark calculations so we keep background and synchronous writeout watermarks in the same ratios after adjusting them for the amout of mapped memory. This ensures we should always attempt to start background writeout before synchronous writeout and preserves the admin's desired background-versus-forground ratios after we've auto-adjusted one of them. Signed-off-by:
Nick Piggin <nickpiggin@cyberone.com.au> Signed-off-by:
-
Hugh Dickins authored
A tmpfs user reported increasingly slow directory reads when repeatedly creating and unlinking in a mkstemp-like way. The negative dentries accumulate alarmingly (until memory pressure finally frees them), and are just a hindrance to any in-memory filesystem. simple_lookup set d_op to arrange for negative dentries to be deleted immediately. (But I failed to discover how it is that on-disk filesystems seem to keep their negative dentries within manageable bounds: this effect was gross with tmpfs or ramfs, but no problem at all with extN or reiser.) Signed-off-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Hugh Dickins authored
Clarify mmgrab by collapsing it into get_task_mm (in fork.c not inline), and commenting on the special case it is guarding against: when use_mm in an AIO daemon temporarily adopts the mm while it's on its way out. Signed-off-by:
-
Marcelo Tosatti authored
Back when we were discussing the need for a memory barrier in sync_page(), it came to me (thanks Andrea!) that the bit operations can be perfectly reordered on architectures other than x86. I think the commentary on i386 bitops.h is misleading, its worth to note that that these operations are not guaranteed not to be reordered on different architectures. clear_bit() already does that: * clear_bit() is atomic and may not be reordered. However, it does * not contain a memory barrier, so if it is used for locking purposes, * you should call smp_mb__before_clear_bit() and/or smp_mb__after_clear_bit() * in order to ensure changes are visible on other processors. Signed-off-by:
-
Hugh Dickins authored
Swapoff can make good use of a page's anon_vma and index, while it's still left in swapcache, or once it's brought back in and the first pte mapped back: unuse_vma go directly to just one page of only those vmas with the same anon_vma. And unuse_process can skip any vmas without an anon_vma (extending the hugetlb check: hugetlb vmas have no anon_vma). This just hacks in on top of the existing procedure, still going through all the vmas of all the mms in mmlist. A more elegant procedure might replace mmlist by a list of anon_vmas: but that would be more work to implement, with apparently more overhead in the common paths. Signed-off-by:
-
Hugh Dickins authored
With page_map_lock out of the way, there's no need for page_referenced and try_to_unmap to use trylocks - provided we switch anon_vma->lock and mm->page_table_lock around in anon_vma_prepare. Though I suppose it's possible that we'll find that vmscan makes better progress with trylocks than spinning - we're free to choose trylocks again if so. Try to update the mm lock ordering documentation in filemap.c. But I still find it confusing, and I've no idea of where to stop. So add an mm lock ordering list I can understand to rmap.c. Signed-off-by:
-
Hugh Dickins authored
With page_map_lock gone, how to stabilize page->mapping's anon_vma while acquiring anon_vma->lock in page_referenced_anon and try_to_unmap_anon? The page cannot actually be freed (vmscan holds reference), but however much we check page_mapped (which guarantees that anon_vma is in use - or would guarantee that if we added suitable barriers), there's no locking against page becoming unmapped the instant after, then anon_vma freed. It's okay to take anon_vma->lock after it's freed, so long as it remains a struct anon_vma (its list would become empty, or perhaps reused for an unrelated anon_vma: but no problem since we always check that the page located is the right one); but corruption if that memory gets reused for some other purpose. This is not unique: it's liable to be problem whenever the kernel tries to approach a structure obliquely. It's generally solved with an atomic reference count; but one advantage of anon_vma over anonmm is that it does not have such a count, and it would be a backward step to add one. Therefore... implement SLAB_DESTROY_BY_RCU flag, to guarantee that such a kmem_cache_alloc'ed structure cannot get freed to other use while the rcu_read_lock is held i.e. preempt disabled; and use that for anon_vma. Fix concerns raised by Manfred: this flag is incompatible with poisoning and destructor, and kmem_cache_destroy needs to synchronize_kernel. I hope SLAB_DESTROY_BY_RCU may be useful elsewhere; but though it's safe for little anon_vma, I'd be reluctant to use it on any caches whose immediate shrinkage under pressure is important to the system. Signed-off-by:
-
Hugh Dickins authored
The pte_chains rmap used pte_chain_lock (bit_spin_lock on PG_chainlock) to lock its pte_chains. We kept this (as page_map_lock: bit_spin_lock on PG_maplock) when we moved to objrmap. But the file objrmap locks its vma tree with mapping->i_mmap_lock, and the anon objrmap locks its vma list with anon_vma->lock: so isn't the page_map_lock superfluous? Pretty much, yes. The mapcount was protected by it, and needs to become an atomic: starting at -1 like page _count, so nr_mapped can be tracked precisely up and down. The last page_remove_rmap can't clear anon page mapping any more, because of races with page_add_rmap; from which some BUG_ONs must go for the same reason, but they've served their purpose. vmscan decisions are naturally racy, little change there beyond removing page_map_lock/unlock. But to stabilize the file-backed page->mapping against truncation while acquiring i_mmap_lock, page_referenced_file now needs page lock to be held even for refill_inactive_zone. There's a similar issue in acquiring anon_vma->lock, where page lock doesn't help: which this patch pretends to handle, but actually it needs the next. Roughly 10% cut off lmbench fork numbers on my 2*HT*P4. Must confess my testing failed to show the races even while they were knowingly exposed: would benefit from testing on racier equipment. Signed-off-by:
-
Hugh Dickins authored
First of a batch of five patches to eliminate rmap's page_map_lock, replace its trylocking by spinlocking, and use anon_vma to speed up swapoff. Patches updated from the originals against 2.6.7-mm7: nothing new so I won't spam the list, but including Manfred's SLAB_DESTROY_BY_RCU fixes, and omitting the unuse_process mmap_sem fix already in 2.6.8-rc3. This patch: Replace the PG_anon page->flags bit by setting the lower bit of the pointer in page->mapping when it's anon_vma: PAGE_MAPPING_ANON bit. We're about to eliminate the locking which kept the flags and mapping in synch: it's much easier to work on a local copy of page->mapping, than worry about whether flags and mapping are in synch (though I imagine it could be done, at greater cost, with some barriers). Signed-off-by:
-
