Messages in this thread Patch in this message |  | | Date | Fri, 27 Apr 2001 19:28:20 +0100 (BST) | From | Mark Hemment <> | Subject | Re: [PATCH] allow PF_MEMALLOC tasks to directly reclaim pages |
| |
Marcelo,
Infact, the test can be made even weaker than that.
We only what to avoid the inactive-clean list when allocating from within an interrupt (or from a bottom-half handler) to avoid deadlock on taking the pagecache_lock and pagemap_lru_lock. Note: no allocations are done while holding either of these locks.
Even GFP_ATOMIC doesn't matter; that simply says if we should block or not (could be an allocation while holding a spinlock, but not inside an interrupt).
I've been doing v heavy load on a 4-way server with;
if (order == 0 && !in_interrupt()) direct_reclaim = 1;
without any problems.
Of course, the in_interrupt() is heavier than (gfp_mask & __GFP_WAIT), but the benefits outweight the slight fattening.
Mark
On Fri, 27 Apr 2001, Marcelo Tosatti wrote:
> > Linus, > > Currently __alloc_pages() does not allow PF_MEMALLOC tasks to free clean > inactive pages. > > This is senseless --- if the allocation has __GFP_WAIT set, its ok to grab > the pagemap_lru_lock/pagecache_lock/etc. > > I checked all possible codepaths after reclaim_page() and they are ok. > > The following patch fixes that. > > > --- linux/mm/page_alloc.c.orig Fri Apr 27 05:59:35 2001 > +++ linux/mm/page_alloc.c Fri Apr 27 05:59:48 2001 > @@ -295,8 +295,7 @@ > * Can we take pages directly from the inactive_clean > * list? > */ > - if (order == 0 && (gfp_mask & __GFP_WAIT) && > - !(current->flags & PF_MEMALLOC)) > + if (order == 0 && (gfp_mask & __GFP_WAIT)) > direct_reclaim = 1; > > /* > > > - > 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/ >
- 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/
|  |