Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
Mel Gorman wrote: On Fri, 26 Jan 2007, Chris Friesen wrote: We currently see this issue on our systems, as we have older e1000 hardware with 9KB jumbo frames. After a while we just fail to allocate buffers and the system goes belly-up. Can you describe a reliable way of triggering this problem? At best, I hear "on our undescribed workload, we sometimes see this problem" but not much in the way of details. I work on embedded server applications. One of our blades is a dual-Xeon with 8GB of RAM and 6 e1000 cards. The hardware is 32-bit only, so we're using the i386 kernel with HIGHMEM64G enabled. This blade acts essentially as storage for other blades in the shelf. Basically all disk and network I/O. After being up for a month or two it starts getting e1000 allocation failures. In some of the cases at least it appears that the page cache has hundreds of megs of freeable memory, but it can't get at that memory to fulfill an atomic allocation. I should point out that we haven't yet tried tuning /proc/sys/vm/min_free_kbytes. The default value on this system is 3831. Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Chris Friesen wrote: Mel Gorman wrote: Worse, the problem is to have high order contiguous blocks free at the time of allocation without reclaim or migration. If the allocations were not atomic, anti-fragmentation as it is today would be enough. Has anyone looked at marking the buffers as "needs refilling" then kick off a kernel thread or something to do the allocations under GFP_KERNEL? I haven't seen it being discussed although it's probably doable as an addition to the existing mempool mechanism. Anti-fragmentation would mean that the non-atomic GFP_KERNEL allocation had a chance of succeeding. That way we avoid having to allocate the buffers with GFP_ATOMIC. Unless the load was so high that the pool was getting depleted and memory under so much pressure that reclaim could not keep up. But yes, it's possible that GFP_ATOMIC allocations could be avoided the majority of times. I seem to recall that the tulip driver used to do this. Is it just too complicated from a race condition standpoint? It shouldn't be that complicated. We currently see this issue on our systems, as we have older e1000 hardware with 9KB jumbo frames. After a while we just fail to allocate buffers and the system goes belly-up. Can you describe a reliable way of triggering this problem? At best, I hear "on our undescribed workload, we sometimes see this problem" but not much in the way of details. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Christoph Lameter wrote: On Fri, 26 Jan 2007, Mel Gorman wrote: The zone-based approach does nothing to help jumbo frame allocations. It only helps hugepage allocations at runtime and potentially memory hot-remove. Sounds like the max order based approach is better in many ways. I agree but too many people are not pleased with the main allocator path being affected and wanted to see zones, so here we are :) Also avoids modifications to vmstat.c/.h ;-) -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
Mel Gorman wrote: Worse, the problem is to have high order contiguous blocks free at the time of allocation without reclaim or migration. If the allocations were not atomic, anti-fragmentation as it is today would be enough. Has anyone looked at marking the buffers as "needs refilling" then kick off a kernel thread or something to do the allocations under GFP_KERNEL? That way we avoid having to allocate the buffers with GFP_ATOMIC. I seem to recall that the tulip driver used to do this. Is it just too complicated from a race condition standpoint? We currently see this issue on our systems, as we have older e1000 hardware with 9KB jumbo frames. After a while we just fail to allocate buffers and the system goes belly-up. Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Mel Gorman wrote: > The zone-based approach does nothing to help jumbo frame allocations. It only > helps hugepage allocations at runtime and potentially memory hot-remove. Sounds like the max order based approach is better in many ways. Also avoids modifications to vmstat.c/.h ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Christoph Lameter wrote: On Fri, 26 Jan 2007, Mel Gorman wrote: It's come up a few times and the converation is always fairly similar although the thread http://lkml.org/lkml/2006/9/22/44 has interesting information on the topic. There has been no serious discussion on whether anti-fragmentation would help it or not. I think it would if atomic allocations were clustered together because then jumbo frame allocations would cluster together in the same MAX_ORDER blocks and tend to keep other allocations away. They are clustered in both schemes together with other non movable allocs right? For the jumbo frame problem, only the antifragmentation approach of clustering types of pages together in MAX_ORDER blocks has any chance of helping. The problem is to defrag while atomic? Worse, the problem is to have high order contiguous blocks free at the time of allocation without reclaim or migration. If the allocations were not atomic, anti-fragmentation as it is today would be enough. By clustering atomic allocations together though, I would expect the jumbo frames to be allocated and freed within the same area without interference from other allocation types as long as min_free_kbytes was also set higher than default. I lack the hardware to prove/disprove the idea though. How is the zone based concept different in that area from the max order block based one? The zone-based approach does nothing to help jumbo frame allocations. It only helps hugepage allocations at runtime and potentially memory hot-remove. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Mel Gorman wrote: > It's come up a few times and the converation is always fairly similar although > the thread http://lkml.org/lkml/2006/9/22/44 has interesting information on > the topic. There has been no serious discussion on whether anti-fragmentation > would help it or not. I think it would if atomic allocations were clustered > together because then jumbo frame allocations would cluster together in the > same MAX_ORDER blocks and tend to keep other allocations away. They are clustered in both schemes together with other non movable allocs right? The problem is to defrag while atomic? How is the zone based concept different in that area from the max order block based one? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Christoph Lameter wrote: On Fri, 26 Jan 2007, Mel Gorman wrote: What is the e1000 problem? Jumbo packet allocation via GFP_KERNEL? Yes. Potentially the anti-fragmentation patches could address this by clustering atomic allocations together as much as possible. GFP_ATOMIC allocs? Yes Do you have a reference to the thread where this was discussed? It's come up a few times and the converation is always fairly similar although the thread http://lkml.org/lkml/2006/9/22/44 has interesting information on the topic. There has been no serious discussion on whether anti-fragmentation would help it or not. I think it would if atomic allocations were clustered together because then jumbo frame allocations would cluster together in the same MAX_ORDER blocks and tend to keep other allocations away. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Mel Gorman wrote: > > What is the e1000 problem? Jumbo packet allocation via GFP_KERNEL? > Yes. Potentially the anti-fragmentation patches could address this by > clustering atomic allocations together as much as possible. GFP_ATOMIC allocs? Do you have a reference to the thread where this was discussed? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Christoph Lameter wrote: On Fri, 26 Jan 2007, Mel Gorman wrote: Because Andrew has made it pretty clear he will not take those patches on the grounds of complexity - at least until it can be shown that they fix the e1000 problem. Any improvement on the behavior of those patches such as address biasing to allow memory hot-remove of the higher addresses makes them even more complex. What is the e1000 problem? Jumbo packet allocation via GFP_KERNEL? Yes. Potentially the anti-fragmentation patches could address this by clustering atomic allocations together as much as possible. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Mel Gorman wrote: > Because Andrew has made it pretty clear he will not take those patches on the > grounds of complexity - at least until it can be shown that they fix the e1000 > problem. Any improvement on the behavior of those patches such as address > biasing to allow memory hot-remove of the higher addresses makes them even > more complex. What is the e1000 problem? Jumbo packet allocation via GFP_KERNEL? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Christoph Lameter wrote: Unmovable allocations in the movable zone. Yuck. I know, but my objective at this time is to allow the hugepage pool to be resized at runtime for situations where the number of required hugepages is not known in advance. Having a zone for movable pages allows that to happen. Also, it's possible that migration of hugepages will be supported at some time in the future. That's a more reasonable possibility than moving kernel memory. Why dont you abandon the whole concept of statically sized movable zone and go back to the nice earlier idea of dynamically assigning MAX_ORDER chunks to be movable or not? Because Andrew has made it pretty clear he will not take those patches on the grounds of complexity - at least until it can be shown that they fix the e1000 problem. Any improvement on the behavior of those patches such as address biasing to allow memory hot-remove of the higher addresses makes them even more complex. Also, almost every time the anti-frag patches are posted, someone suggests that zones be used instead. I wanted to show what those patches look like. (of course, every time I post the zone approach, someone suggests I go back the other way) -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
Unmovable allocations in the movable zone. Yuck. Why dont you abandon the whole concept of statically sized movable zone and go back to the nice earlier idea of dynamically assigning MAX_ORDER chunks to be movable or not? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
Unmovable allocations in the movable zone. Yuck. Why dont you abandon the whole concept of statically sized movable zone and go back to the nice earlier idea of dynamically assigning MAX_ORDER chunks to be movable or not? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Christoph Lameter wrote: Unmovable allocations in the movable zone. Yuck. I know, but my objective at this time is to allow the hugepage pool to be resized at runtime for situations where the number of required hugepages is not known in advance. Having a zone for movable pages allows that to happen. Also, it's possible that migration of hugepages will be supported at some time in the future. That's a more reasonable possibility than moving kernel memory. Why dont you abandon the whole concept of statically sized movable zone and go back to the nice earlier idea of dynamically assigning MAX_ORDER chunks to be movable or not? Because Andrew has made it pretty clear he will not take those patches on the grounds of complexity - at least until it can be shown that they fix the e1000 problem. Any improvement on the behavior of those patches such as address biasing to allow memory hot-remove of the higher addresses makes them even more complex. Also, almost every time the anti-frag patches are posted, someone suggests that zones be used instead. I wanted to show what those patches look like. (of course, every time I post the zone approach, someone suggests I go back the other way) -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Mel Gorman wrote: Because Andrew has made it pretty clear he will not take those patches on the grounds of complexity - at least until it can be shown that they fix the e1000 problem. Any improvement on the behavior of those patches such as address biasing to allow memory hot-remove of the higher addresses makes them even more complex. What is the e1000 problem? Jumbo packet allocation via GFP_KERNEL? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Christoph Lameter wrote: On Fri, 26 Jan 2007, Mel Gorman wrote: Because Andrew has made it pretty clear he will not take those patches on the grounds of complexity - at least until it can be shown that they fix the e1000 problem. Any improvement on the behavior of those patches such as address biasing to allow memory hot-remove of the higher addresses makes them even more complex. What is the e1000 problem? Jumbo packet allocation via GFP_KERNEL? Yes. Potentially the anti-fragmentation patches could address this by clustering atomic allocations together as much as possible. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Mel Gorman wrote: What is the e1000 problem? Jumbo packet allocation via GFP_KERNEL? Yes. Potentially the anti-fragmentation patches could address this by clustering atomic allocations together as much as possible. GFP_ATOMIC allocs? Do you have a reference to the thread where this was discussed? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Christoph Lameter wrote: On Fri, 26 Jan 2007, Mel Gorman wrote: What is the e1000 problem? Jumbo packet allocation via GFP_KERNEL? Yes. Potentially the anti-fragmentation patches could address this by clustering atomic allocations together as much as possible. GFP_ATOMIC allocs? Yes Do you have a reference to the thread where this was discussed? It's come up a few times and the converation is always fairly similar although the thread http://lkml.org/lkml/2006/9/22/44 has interesting information on the topic. There has been no serious discussion on whether anti-fragmentation would help it or not. I think it would if atomic allocations were clustered together because then jumbo frame allocations would cluster together in the same MAX_ORDER blocks and tend to keep other allocations away. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Mel Gorman wrote: It's come up a few times and the converation is always fairly similar although the thread http://lkml.org/lkml/2006/9/22/44 has interesting information on the topic. There has been no serious discussion on whether anti-fragmentation would help it or not. I think it would if atomic allocations were clustered together because then jumbo frame allocations would cluster together in the same MAX_ORDER blocks and tend to keep other allocations away. They are clustered in both schemes together with other non movable allocs right? The problem is to defrag while atomic? How is the zone based concept different in that area from the max order block based one? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Christoph Lameter wrote: On Fri, 26 Jan 2007, Mel Gorman wrote: It's come up a few times and the converation is always fairly similar although the thread http://lkml.org/lkml/2006/9/22/44 has interesting information on the topic. There has been no serious discussion on whether anti-fragmentation would help it or not. I think it would if atomic allocations were clustered together because then jumbo frame allocations would cluster together in the same MAX_ORDER blocks and tend to keep other allocations away. They are clustered in both schemes together with other non movable allocs right? For the jumbo frame problem, only the antifragmentation approach of clustering types of pages together in MAX_ORDER blocks has any chance of helping. The problem is to defrag while atomic? Worse, the problem is to have high order contiguous blocks free at the time of allocation without reclaim or migration. If the allocations were not atomic, anti-fragmentation as it is today would be enough. By clustering atomic allocations together though, I would expect the jumbo frames to be allocated and freed within the same area without interference from other allocation types as long as min_free_kbytes was also set higher than default. I lack the hardware to prove/disprove the idea though. How is the zone based concept different in that area from the max order block based one? The zone-based approach does nothing to help jumbo frame allocations. It only helps hugepage allocations at runtime and potentially memory hot-remove. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Mel Gorman wrote: The zone-based approach does nothing to help jumbo frame allocations. It only helps hugepage allocations at runtime and potentially memory hot-remove. Sounds like the max order based approach is better in many ways. Also avoids modifications to vmstat.c/.h ;-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
Mel Gorman wrote: Worse, the problem is to have high order contiguous blocks free at the time of allocation without reclaim or migration. If the allocations were not atomic, anti-fragmentation as it is today would be enough. Has anyone looked at marking the buffers as needs refilling then kick off a kernel thread or something to do the allocations under GFP_KERNEL? That way we avoid having to allocate the buffers with GFP_ATOMIC. I seem to recall that the tulip driver used to do this. Is it just too complicated from a race condition standpoint? We currently see this issue on our systems, as we have older e1000 hardware with 9KB jumbo frames. After a while we just fail to allocate buffers and the system goes belly-up. Chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Christoph Lameter wrote: On Fri, 26 Jan 2007, Mel Gorman wrote: The zone-based approach does nothing to help jumbo frame allocations. It only helps hugepage allocations at runtime and potentially memory hot-remove. Sounds like the max order based approach is better in many ways. I agree but too many people are not pleased with the main allocator path being affected and wanted to see zones, so here we are :) Also avoids modifications to vmstat.c/.h ;-) -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
On Fri, 26 Jan 2007, Chris Friesen wrote: Mel Gorman wrote: Worse, the problem is to have high order contiguous blocks free at the time of allocation without reclaim or migration. If the allocations were not atomic, anti-fragmentation as it is today would be enough. Has anyone looked at marking the buffers as needs refilling then kick off a kernel thread or something to do the allocations under GFP_KERNEL? I haven't seen it being discussed although it's probably doable as an addition to the existing mempool mechanism. Anti-fragmentation would mean that the non-atomic GFP_KERNEL allocation had a chance of succeeding. That way we avoid having to allocate the buffers with GFP_ATOMIC. Unless the load was so high that the pool was getting depleted and memory under so much pressure that reclaim could not keep up. But yes, it's possible that GFP_ATOMIC allocations could be avoided the majority of times. I seem to recall that the tulip driver used to do this. Is it just too complicated from a race condition standpoint? It shouldn't be that complicated. We currently see this issue on our systems, as we have older e1000 hardware with 9KB jumbo frames. After a while we just fail to allocate buffers and the system goes belly-up. Can you describe a reliable way of triggering this problem? At best, I hear on our undescribed workload, we sometimes see this problem but not much in the way of details. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE
Mel Gorman wrote: On Fri, 26 Jan 2007, Chris Friesen wrote: We currently see this issue on our systems, as we have older e1000 hardware with 9KB jumbo frames. After a while we just fail to allocate buffers and the system goes belly-up. Can you describe a reliable way of triggering this problem? At best, I hear on our undescribed workload, we sometimes see this problem but not much in the way of details. I work on embedded server applications. One of our blades is a dual-Xeon with 8GB of RAM and 6 e1000 cards. The hardware is 32-bit only, so we're using the i386 kernel with HIGHMEM64G enabled. This blade acts essentially as storage for other blades in the shelf. Basically all disk and network I/O. After being up for a month or two it starts getting e1000 allocation failures. In some of the cases at least it appears that the page cache has hundreds of megs of freeable memory, but it can't get at that memory to fulfill an atomic allocation. I should point out that we haven't yet tried tuning /proc/sys/vm/min_free_kbytes. The default value on this system is 3831. Chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
