Messages in this thread |  | | Date | Thu, 24 May 2001 08:03:49 -0300 (BRST) | From | Rik van Riel <> | Subject | Re: [RFC][PATCH] Re: Linux 2.4.4-ac10 |
| |
On Thu, 24 May 2001, Mike Galbraith wrote: > On Thu, 24 May 2001, Rik van Riel wrote: > > On Thu, 24 May 2001, Mike Galbraith wrote: > > > On Sun, 20 May 2001, Rik van Riel wrote: > > > > > > > Remember that inactive_clean pages are always immediately > > > > reclaimable by __alloc_pages(), if you measured a performance > > > > difference by freeing pages in a different way I'm pretty sure > > > > it's a side effect of something else. What that something > > > > else is I'm curious to find out, but I'm pretty convinced that > > > > throwing away data early isn't the way to go. > > > > > > OK.. let's forget about throughput for a moment and consider > > > those annoying reports of 0 order allocations failing :) > > > > Those are ok. All failing 0 order allocations are either > > atomic allocations or GFP_BUFFER allocations. I guess we > > should just remove the printk() ;) > > Hmm. The guy who's box locks up on him after a burst of these > probably doesn't think these failures are very OK ;-) I don't > think order 0 failing is cool at all.. ever.
You may not think it's cool, but it's needed in order to prevent deadlocks. Just because an allocation cannot do disk IO or sleep, that's no reason to loop around like crazy in __alloc_pages() and hang the machine ... ;)
> A (long) while back, Linus specifically mentioned worrying > about atomic allocation reliability.
That's a separate issue. That was, IIRC, about the failure of atomic allocations causing packet loss on Linux routers and, because of that, poor performance.
This is something we still need to look into, but basically this problem is about too high latency and NOT about "pre-freeing" more pages (like your patch attempts). If this problem is still an issue, it's quite likely that the VM is holding locks for too long so that it cannot react fast enough to free up some inactive_clean pages.
regards,
Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml
Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose...
http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |