Messages in this thread | | | Date | Mon, 27 Aug 2001 17:17:59 -0300 (BRT) | From | Marcelo Tosatti <> | Subject | Re: patch-2.4.10-pre1 |
| |
On Mon, 27 Aug 2001, Linus Torvalds wrote:
> > On Mon, 27 Aug 2001, Marcelo Tosatti wrote: > > > > There have been some reports of x-order allocation failures when you where > > in Finland. They can be triggered by high IO stress on highmem machines. > > > > The following patch avoids that by allowing tasks allocating bounce memory > > (lowmem) to block on low mem IO, thus applying more "IO pressure" to the > > lowmem zone. (the lowmem zone is our "IOable memory" anyway, so...) > > I'd much rather set this up by splitting up __GFP_IO into two parts (ie > __GFP_IO and __GFP_IO_BOUNCE), and avoiding have "negative" bits in the > gfp_mask. That way the bits in gfp_mask always end up increasing things we > can do, not ever decreasing them. > > Also, your test is really wrong: > > page->zone != &pgdat_list->node_zones[ZONE_HIGHMEM] > > is bogus and assumes MUCH too intimate knowledge of there being only one > particular zone that is "highmem" (think NUMA machines where each node may > have its own highmem setup). So it SHOULD be something along the lines of > > #ifdef CONFIG_HIGHMEM > if (!(gfp_mask & __GFP_HIGHIO) && PageHighMem(page)) > return; > #endif > > inside the write case of sync_page_buffers() (we can, and probably should, > still _wait_ for highmem buffers - but whether we do it inside > sync_page_buffers() or inside try_to_free_buffers() is probably mostly a > matter of taste - I won't argue too much with your choice there). > > Other than that, the basic approach looks sane, I would just prefer for > the testing and bits to be done more regularly.
Great. I really expected you to be grumpy about the implementation :)
Will implement the idea decently and send you the patch later.
- 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/
| |