- 26 Sep, 2006 40 commits
-
-
Christoph Lameter authored
Make ZONE_HIGHMEM optional - ifdef out code and definitions related to CONFIG_HIGHMEM - __GFP_HIGHMEM falls back to normal allocations if there is no ZONE_HIGHMEM - GFP_ZONEMASK becomes 0x01 if there is no DMA32 and no HIGHMEM zone. [jdike@addtoit.com: build fix] Signed-off-by:
Jeff Dike <jdike@addtoit.com> Signed-off-by:
Christoph Lameter <clameter@engr.sgi.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Christoph Lameter authored
Make ZONE_DMA32 optional - Add #ifdefs around ZONE_DMA32 specific code and definitions. - Add CONFIG_ZONE_DMA32 config option and use that for x86_64 that alone needs this zone. - Remove the use of CONFIG_DMA_IS_DMA32 and CONFIG_DMA_IS_NORMAL for ia64 and fix up the way per node ZVCs are calculated. - Fall back to prior GFP_ZONEMASK of 0x03 if there is no DMA32 zone. Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
Christoph Lameter authored
Use enum for zones and reformat zones dependent information Add comments explaning the use of zones and add a zones_t type for zone numbers. Line up information that will be #ifdefd by the following patches. [akpm@osdl.org: comment cleanups] Signed-off-by:
-
Christoph Lameter authored
page allocator ZONE_HIGHMEM fixups 1. We do not need to do an #ifdef in si_meminfo since both counters in use are zero if !CONFIG_HIGHMEM. 2. Add #ifdef in si_meminfo_node instead to avoid referencing zone information for ZONE_HIGHMEM if we do not have HIGHMEM (may not be there after the following patches). 3. Replace the use of ZONE_HIGHMEM with MAX_NR_ZONES in build_zonelists_node 4. build_zonelists_node: Remove BUG_ON for ZONE_HIGHMEM. Zone will be optional soon and thus BUG_ON cannot be triggered anymore. 5. init_free_area_core: Replace a use of ZONE_HIGHMEM with NR_MAX_ZONES. [akpm@osdl.org: cleanups] Signed-off-by:
-
Christoph Lameter authored
Move totalhigh_pages and nr_free_highpages() into highmem.c/.h Move the totalhigh_pages definition into highmem.c/.h. Move the nr_free_highpages function into highmem.c [yoichi_yuasa@tripeaks.co.jp: build fix] Signed-off-by:
Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Signed-off-by:
-
Christoph Lameter authored
Do not display HIGHMEM memory sizes if CONFIG_HIGHMEM is not set. Make HIGHMEM dependent texts and make display of highmem counters optional Some texts are depending on CONFIG_HIGHMEM. Remove those strings and remove the display of highmem counter values if CONFIG_HIGHMEM is not set. [akpm@osdl.org: remove some ifdefs] Signed-off-by:
-
Christoph Lameter authored
Fix array initialization in lots of arches The number of zones may now be reduced from 4 to 2 for many arches. Fix the array initialization for the zones array for all architectures so that it is not initializing a fixed number of elements. Signed-off-by:
-
Christoph Lameter authored
I keep seeing zones on various platforms that are never used and wonder why we compile support for them into the kernel. Counters show up for HIGHMEM and DMA32 that are alway zero. This patch allows the removal of ZONE_DMA32 for non x86_64 architectures and it will get rid of ZONE_HIGHMEM for arches not using highmem (like 64 bit architectures). If an arch does not define CONFIG_HIGHMEM then ZONE_HIGHMEM will not be defined. Similarly if an arch does not define CONFIG_ZONE_DMA32 then ZONE_DMA32 will not be defined. No current architecture uses all the 4 zones (DMA,DMA32,NORMAL,HIGH) that we have now. The patchset will reduce the number of zones for all platforms. On many platforms that do not have DMA32 or HIGHMEM this will reduce the number of zones by 50%. F.e. ia64 only uses DMA and NORMAL. Large amounts of memory can be saved for larger systemss that may have a few hundred NUMA nodes. With ZONE_DMA32 and ZONE_HIGHMEM support optional MAX_NR_ZONES will be 2 for many non i386 platforms and even for i386 without CONFIG_HIGHMEM set. Tested on ia64, x86_64 and on i386 with and without highmem. The patchset consists of 11 patches that are following this message. One could go even further than this patchset and also make ZONE_DMA optional because some platforms do not need a separate DMA zone and can do DMA to all of memory. This could reduce MAX_NR_ZONES to 1. Such a patchset will hopefully follow soon. This patch: Fix strange uses of MAX_NR_ZONES Sometimes we use MAX_NR_ZONES - x to refer to a zone. Make that explicit. Signed-off-by:
-
Franck Bui-Huu authored
It fixes various coding style issues, specially when spaces are useless. For example '*' go next to the function name. Signed-off-by:
Franck Bui-Huu <vagabon.xyz@gmail.com> Cc: Dave Hansen <haveblue@us.ibm.com> Signed-off-by:
-
Franck Bui-Huu authored
It also creates get_mapsize() helper in order to make the code more readable when it calculates the boot bitmap size. Signed-off-by:
-
Franck Bui-Huu authored
Signed-off-by:
-
Franck Bui-Huu authored
Signed-off-by:
-
Franck Bui-Huu authored
Signed-off-by:
-
Franck Bui-Huu authored
Signed-off-by:
-
Franck Bui-Huu authored
__init in headers is pretty useless because the compiler doesn't check it, and they get out of sync relatively frequently. So if you see an __init in a header file, it's quite unreliable and you need to check the definition anyway. Signed-off-by:
-
keith mannthey authored
Address a long standing issue of booting with an initrd on an i386 numa system. Currently (and always) the numa kva area is mapped into low memory by finding the end of low memory and moving that mark down (thus creating space for the kva). The issue with this is that Grub loads initrds into this similar space so when the kernel check the initrd it finds it outside max_low_pfn and disables it (it thinks the initrd is not mapped into usable memory) thus initrd enabled kernels can't boot i386 numa :( My solution to the problem just converts the numa kva area to use the bootmem allocator to save it's area (instead of moving the end of low memory). Using bootmem allows the kva area to be mapped into more diverse addresses (not just the end of low memory) and enables the kva area to be mapped below the initrd if present. I have tested this patch on numaq(no initrd) and summit(initrd) i386 numa based systems. [akpm@osdl.org: cleanups] Signed-off-by:
Keith Mannthey <kmannth@us.ibm.com> Signed-off-by:
-
Adrian Bunk authored
This patch makes the following needlessly global functions static: - slab.c: kmem_find_general_cachep() - swap.c: __page_cache_release() - vmalloc.c: __vmalloc_node() Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Peter Zijlstra authored
With the tracking of dirty pages properly done now, msync doesn't need to scan the PTEs anymore to determine the dirty status. From: Hugh Dickins <hugh@veritas.com> In looking to do that, I made some other tidyups: can remove several #includes, and sys_msync loop termination not quite right. Most of those points are criticisms of the existing sys_msync, not of your patch. In particular, the loop termination errors were introduced in 2.6.17: I did notice this shortly before it came out, but decided I was more likely to get it wrong myself, and make matters worse if I tried to rush a last-minute fix in. And it's not terribly likely to go wrong, nor disastrous if it does go wrong (may miss reporting an unmapped area; may also fsync file of a following vma). Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Peter Zijlstra authored
Wrt. the recent modifications in do_wp_page() Hugh Dickins pointed out: "I now realize it's right to the first order (normal case) and to the second order (ptrace poke), but not to the third order (ptrace poke anon page here to be COWed - perhaps can't occur without intervening mprotects)." This patch restores the old COW behaviour for anonymous pages. Signed-off-by:
-
Peter Zijlstra authored
Smallish cleanup to install_page(), could save a memory read (haven't checked the asm output) and sure looks nicer. Signed-off-by:
-
Peter Zijlstra authored
mprotect() resets the page protections, which could result in extra write faults for those pages whose dirty state we track using write faults and are dirty already. Signed-off-by:
-
Peter Zijlstra authored
Now that we can detect writers of shared mappings, throttle them. Avoids OOM by surprise. Signed-off-by:
-
Peter Zijlstra authored
Tracking of dirty pages in shared writeable mmap()s. The idea is simple: write protect clean shared writeable pages, catch the write-fault, make writeable and set dirty. On page write-back clean all the PTE dirty bits and write protect them once again. The implementation is a tad harder, mainly because the default backing_dev_info capabilities were too loosely maintained. Hence it is not enough to test the backing_dev_info for cap_account_dirty. The current heuristic is as follows, a VMA is eligible when: - its shared writeable (vm_flags & (VM_WRITE|VM_SHARED)) == (VM_WRITE|VM_SHARED) - it is not a 'special' mapping (vm_flags & (VM_PFNMAP|VM_INSERTPAGE)) == 0 - the backing_dev_info is cap_account_dirty mapping_cap_account_dirty(vma->vm_file->f_mapping) - f_op->mmap() didn't change the default page protection Page from remap_pfn_range() are explicitly excluded because their COW semantics are already horrid enough (see vm_normal_page() in do_wp_page()) and because they don't have a backing store anyway. mprotect() is taught about the new behaviour as well. However it overrides the last condition. Cleaning the pages on write-back is done with page_mkclean() a new rmap call. It can be called on any page, but is currently only implemented for mapped pages, if the page is found the be of a VMA that accounts dirty pages it will also wrprotect the PTE. Finally, in fs/buffers.c:try_to_free_buffers(); remove clear_page_dirty() from under ->private_lock. This seems to be safe, since ->private_lock is used to serialize access to the buffers, not the page itself. This is needed because clear_page_dirty() will call into page_mkclean() and would thereby violate locking order. [dhowells@redhat.com: Provide a page_mkclean() implementation for NOMMU] Signed-off-by:David Howells <dhowells@redhat.com> Signed-off-by:
-
Nick Piggin authored
Introduce a VM_BUG_ON, which is turned on with CONFIG_DEBUG_VM. Use this in the lightweight, inline refcounting functions; PageLRU and PageActive checks in vmscan, because they're pretty well confined to vmscan. And in page allocate/free fastpaths which can be the hottest parts of the kernel for kbuilds. Unlike BUG_ON, VM_BUG_ON must not be used to execute statements with side-effects, and should not be used outside core mm code. Signed-off-by:
Nick Piggin <npiggin@suse.de> Cc: Hugh Dickins <hugh@veritas.com> Cc: Christoph Lameter <clameter@engr.sgi.com> Signed-off-by:
-
James Bottomley authored
Give non-highmem architectures access to the kmap API for the purposes of overriding (this is what the attached patch does). The proposal is that we should now require all architectures with coherence issues to manage data coherence via the kmap/kunmap API. Thus driver writers never have to write code like kmap(page) modify data in page flush_kernel_dcache_page(page) kunmap(page) instead, kmap/kunmap will manage the coherence and driver (and filesystem) writers don't need to worry about how to flush between kmap and kunmap. For most architectures, the page only needs to be flushed if it was actually written to *and* there are user mappings of it, so the best implementation looks to be: clear the page dirty pte bit in the kernel page tables on kmap and on kunmap, check page->mappings for user maps, and then the dirty bit, and only flush if it both has user mappings and is dirty. Signed-off-by: -
Jan Kara authored
Original commit code assumes, that when a buffer on BJ_SyncData list is locked, it is being written to disk. But this is not true and hence it can lead to a potential data loss on crash. Also the code didn't count with the fact that journal_dirty_data() can steal buffers from committing transaction and hence could write buffers that no longer belong to the committing transaction. Finally it could possibly happen that we tried writing out one buffer several times. The patch below tries to solve these problems by a complete rewrite of the data commit code. We go through buffers on t_sync_datalist, lock buffers needing write out and store them in an array. Buffers are also immediately refiled to BJ_Locked list or unfiled (if the write out is completed). When the array is full or we have to block on buffer lock, we submit all accumulated buffers for IO. [suitable for 2.6.18.x around the 2.6.19-rc2 timeframe] Signed-off-by:
Jan Kara <jack@suse.cz> Cc: Badari Pulavarty <pbadari@us.ibm.com> Cc: <stable@kernel.org> Signed-off-by:
-
Jan Blunck authored
get_cpu_var()/per_cpu()/__get_cpu_var() arguments must be simple identifiers. Otherwise the arch dependent implementations might break. This patch enforces the correct usage of the macros by producing a syntax error if the variable is not a simple identifier. Signed-off-by:
Jan Blunck <jblunck@suse.de> Signed-off-by:
-
Christoph Lameter authored
The scheduler will stop load balancing if the most busy processor contains processes pinned via processor affinity. The scheduler currently only does one search for busiest cpu. If it cannot pull any tasks away from the busiest cpu because they were pinned then the scheduler goes into a corner and sulks leaving the idle processors idle. F.e. If you have processor 0 busy running four tasks pinned via taskset, there are none on processor 1 and one just started two processes on processor 2 then the scheduler will not move one of the two processes away from processor 2. This patch fixes that issue by forcing the scheduler to come out of its corner and retrying the load balancing by considering other processors for load balancing. This patch was originally developed by John Hawkes and discussed at http://marc.theaimsgroup.com/?l=linux-kernel&m=113901368523205&w=2. I have removed extraneous material and gone back to equipping struct rq with the cpu the queue is associated with since this makes the patch much easier and it is likely that others in the future will have the same difficulty of figuring out which processor owns which runqueue. The overhead added through these patches is a single word on the stack if the kernel is configured to support 32 cpus or less (32 bit). For 32 bit environments the maximum number of cpus that can be configued is 255 which would result in the use of 32 bytes additional on the stack. On IA64 up to 1k cpus can be configured which will result in the use of 128 additional bytes on the stack. The maximum additional cache footprint is one cacheline. Typically memory use will be much less than a cacheline and the additional cpumask will be placed on the stack in a cacheline that already contains other local variable. Signed-off-by: -
Linus Torvalds authored
* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev: [libata] Fix oops introduced in non-uniform port handling fix [PATCH] ata-piix: fixes kerneldoc error
-
Jeff Garzik authored
Noticed by several people. Signed-off-by:Jeff Garzik <jeff@garzik.org>
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6: [NetLabel]: update docs with website information [NetLabel]: rework the Netlink attribute handling (part 2) [NetLabel]: rework the Netlink attribute handling (part 1) [Netlink]: add nla_validate_nested() [NETLINK]: add nla_for_each_nested() to the interface list [NetLabel]: change the SELinux permissions [NetLabel]: make the CIPSOv4 cache spinlocks bottom half safe [NetLabel]: correct improper handling of non-NetLabel peer contexts [TCP]: make cubic the default [TCP]: default congestion control menu [ATM] he: Fix __init/__devinit conflict [NETFILTER]: Add dscp,DSCP headers to header-y [DCCP]: Introduce dccp_probe [DCCP]: Use constants for CCIDs [DCCP]: Introduce constants for CCID numbers [DCCP]: Allow default/fallback service code.
-
Linus Torvalds authored
* master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6: [SOUND] sparc/amd7930: Use __devinit and __devinitdata as needed. [SUNLANCE]: Mark sparc_lance_probe_one as __devinit. [SPARC64]: Fix section-mismatch errors in solaris emul module.
-
Jonathan Corbet authored
The v4l2 API documentation for VIDIOC_ENUMSTD says: To enumerate all standards applications shall begin at index zero, incrementing by one until the driver returns EINVAL. The actual code, however, tests the index this way: if (index<=0 || index >= vfd->tvnormsize) { ret=-EINVAL; So any application which passes in index=0 gets EINVAL right off the bat - and, in fact, this is what happens to mplayer. So I think the following patch is called for, and maybe even appropriate for a 2.6.18.x stable release. Signed-off-by:Jonathan Corbet <corbet@lwn.net> Cc: Mauro Carvalho Chehab <mchehab@infradead.org> Cc: <stable@kernel.org> Signed-off-by:
-
Ed Swierk authored
Invoking load_module() before param_sysfs_init() is called crashes in mod_sysfs_setup(), since the kset in module_subsys is not initialized yet. In my case, net-pf-1 is getting modprobed as a result of hotplug trying to create a UNIX socket. Calls to hotplug begin after the topology_init initcall. Another patch for the same symptom (module_subsys-initialize-earlier.patch) moves param_sysfs_init() to the subsys initcalls, but this is still not early enough in the boot process in some cases. In particular, topology_init() causes /sbin/hotplug to run, which requests net-pf-1 (the UNIX socket protocol) which can be compiled as a module. Moving param_sysfs_init() to the postcore initcalls fixes this particular race, but there might well be other cases where a usermodehelper causes a module to load earlier still. The patch makes load_module() return an error rather than crashing the kernel if invoked before module_subsys is initialized. Cc: Mark Huang <mlhuang@cs.princeton.edu> Cc: Greg KH <greg@kroah.com> Cc: <stable@kernel.org> Signed-off-by:
-
keith mannthey authored
If there is only 1 node in the system cpus should think they are apart of some other node. If cases where a real numa system boots the Flat numa option make sure the cpus don't claim to be apart on a non-existent node. Signed-off-by:
-
KAMEZAWA Hiroyuki authored
Assume that a cpu is *physically* offlined at boot time... Because smpboot.c::smp_boot_cpu_map() canoot find cpu's sapicid, numa.c::build_cpu_to_node_map() cannot build cpu<->node map for offlined cpu. For such cpus, cpu_to_node map should be fixed at cpu-hot-add. This mapping should be done before cpu onlining. This patch also handles cpu hotremove case. Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: <stable@kernel.org> Signed-off-by:
-
KAMEZAWA Hiroyuki authored
Problem description: We have additional_cpus= option for allocating possible_cpus. But nid for possible cpus are not fixed at boot time. cpus which is offlined at boot or cpus which is not on SRAT is not tied to its node. This will cause panic at cpu onlining. Usually, pxm_to_nid() mapping is fixed at boot time by SRAT. But, unfortunately, some system (my system!) do not include full SRAT table for possible cpus. (Then, I use additiona_cpus= option.) For such possible cpus, pxm<->nid should be fixed at hot-add. We now have acpi_map_pxm_to_node() which is also used at boot. It's suitable here. Signed-off-by:
-
Michael Hanselmann authored
Seems like not all drivers use the framebuffer_alloc() function and won't have an initialized mutex. But those don't have a backlight, anyway. Signed-off-by:
Michael Hanselmann <linux-kernel@hansmi.ch> Cc: Olaf Hering <olaf@aepfle.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Daniel R Thompson <daniel.thompson@st.com> Cc: Jon Smirl <jonsmirl@gmail.com> Cc: <stable@kernel.org> Signed-off-by:
-
David Rientjes authored
Stops panic associated with attempting to free a non slab-allocated per_cpu_pageset. Signed-off-by:
David Rientjes <rientjes@cs.washington.edu> Acked-by:
-
keith mannthey authored
With CONFIG_PHYSICAL_START set to a non default values the i386 boot_ioremap code calculated its pte index wrong and users of boot_ioremap have their areas incorrectly mapped (for me SRAT table not mapped during early boot). This patch removes the addr < BOOT_PTE_PTRS constraint. [ Keith says this is applicable to 2.6.16 and 2.6.17 as well ] Signed-off-by: Keith Mannthey<kmannth@us.ibm.com> Cc: Vivek Goyal <vgoyal@in.ibm.com> Cc: Dave Hansen <haveblue@us.ibm.com> Cc: <stable@kernel.org> Cc: Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
