linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* Re: slablru for 2.5.32-mm1
@ 2002-08-28 22:11 Ed Tomlinson
  0 siblings, 0 replies; 18+ messages in thread
From: Ed Tomlinson @ 2002-08-28 22:11 UTC (permalink / raw)
  To: linux-mm

On August 28, 2002 05:24 pm, Andrew Morton wrote:
> Ed Tomlinson wrote:
> > Hi Andrew
> >
> > Here is slablru for 32-mm1.  This is based on a version ported to
> > 31ish-mm1.  It should be stable.  Its been booted as UP (32-mm1) and SMP
> > on UP  (31ish-mm1 only) and works as expected.
>
> Cool.  But the diff adds tons of stuff which is already added by -mm1.
> I suspect you diffed against 2.5.31 base?

Actually it was a typo.  I use bk for almost all my trees,  I typed the wrong 
rev number when generating the patch.  Net effect was a diff against
2.5.31 base.

> > Andrew, what do you thing about adding slablru to your experimental dir?
>
> No probs.

Thanks - I will not resend here.  Once its online I will announce here and on 
lkml.

> > One interesting change in this version.  We only add the first page of a
> > slab to the lru.  The reference bit setting logic for slabs has been
> > modified to set the bit on the first page. Pagevec created a little bit
> > of a problem for slablru.  How do we know the order of the slab page when
> > its being freed?   My solution is to use 3 bits in page->flags and save
> > the order there.  Then free_pages_ok was modified to take the order from
> > page->flags.  This was implement in a minimal fashion.  Think Wli is
> > working on a more elaborate version of this - fleshed out, it could be
> > used to support large pages in the vm.
>
> hm.  What happened to the idea of walking mem_map[], looking for
> continuation pages? (This would need to be done via pfn_to_page(), I
> guess).

Frankly, that idea made me shutter at bit.  Think this implementation is
cleaner at the expense of 3 bits (slab.c limits slab orders to 5) or 4 bits 
(system wide order limit is 10) if we use this for large 'page' support - 
Wli's comment was that code looked almost the same we just use 
different bits and names.  Think this way is safer and faster, costing 
a couple of bits more than the continuation page idea.

> > Second topic.
> >
> > I have also included an optimisation for vmscan.  I found that the
> > current code would reduce the inactive list to almost nothing when
> > applications create large numbers of active pages very quickly run (ie.
> > gimp loading and editing large 20m+ tiffs).  This reduces the problem.  
> > Always allowing nr_pages to be scanned caused the active list to be
> > reduced to almost nothing when something like gimp exited and we had
> > another task adding lots to the inactive list.  This is fixed here too. 
> > I do wonder if zone->refill_counter, as implemented, is a great idea.  Do
> > we really need/want to remember to scan the active list if it has
> > massively decreased in size because some app exited?  Maybe some sort of
> > decay logic should be used...
>
> Well the refill counter thingy is just an optimisation: rather than calling
> refill_inacative() lots of times to just grab two or three pages, we wait
> until it builds up to 32, and then go deactivate 32 pages.
>
> But ugh, it's a bit broken.  Yup, you're right.  Need to s/if/while/ in
> shrink_zone().

In some ways just do a simple s/if/while/ might be better.  This would
solve the 'memory' problem at the expense of more list activity.

> But we do need to slowly sift through the active list even when the
> inactive list is enormously bigger.  Otherwise, completely dead pages will
> remain in-core forever if there's a lot of pagecache activity going on.

Yes.  When I originally coded slablru I put the pages on the active list.  Turned
out that the time it took them to get to the bottom of the inactive list was such
that I ended up with _lots_ of dead pages in the active list... 

Ed

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: slablru for 2.5.32-mm1
@ 2002-09-06  4:07 Craig Kulesa
  2002-09-06  4:24 ` Robert Love
  2002-09-06  4:38 ` Andrew Morton
  0 siblings, 2 replies; 18+ messages in thread
From: Craig Kulesa @ 2002-09-06  4:07 UTC (permalink / raw)
  To: linux-mm; +Cc: Andrew Morton, Ed Tomlinson

Ed Tomlinson wrote:
>> Andrew Morton wrote:
>>
>> The patch does a zillion BUG->BUG_ON conversions in slab.c, which is a
>> bit unfortunate, because it makes it a bit confusing to review.  Let's
>> do that in a standalone patch next time ;)
>
> Yes.  I would have left the BUG_ONs till later.  Craig thought 
> otherwise.  I do agree two patches would have been better.

I agree also.  I never imagined that patch would make it up the ladder
before the BUG_ON's changes got split out into a separate patch.  Sorry!
So... since I introduced the BUG_ON's, I thought I should clean it up.  

This is mostly for Ed and Andrew, but at:
	http://loke.as.arizona.edu/~ckulesa/kernel/rmap-vm/2.5.33/

you can get a copy of Andrew's slablru.patch from the 2.5.33-mm3 series
where I have altered fs/dcache.c and mm/slab.c (whose patches otherwise
apply cleanly to vanilla 2.5.33) to remove the BUG_ON changes.  It does
reduce the size of the patch, and improves its readability considerably.  
Hope that helps. 

----

I have a terribly naive question to add though.  From the original message 
in this thread, Andrew reverted this BUG_ON due to side-effects:

	BUG_ON(smp_call_function(func, arg, 1, 1));

I must be dense -- why?  All we are doing is passing gcc the hint that
this is an unlikely path, and surely that's true?  I mean, if it's not, 
don't we have other things to worry about?


Best regards,

Craig Kulesa
Steward Observatory
University of Arizona

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: MM patches against 2.5.31
@ 2002-08-26 22:09 Ed Tomlinson
  2002-08-26 23:58 ` Andrew Morton
  0 siblings, 1 reply; 18+ messages in thread
From: Ed Tomlinson @ 2002-08-26 22:09 UTC (permalink / raw)
  To: linux-mm, linux-kernel; +Cc: Andrew Morton, Christian Ehrhardt, Daniel Phillips

This seems to have been missed: 

Linus Torvalds wrote:

> In article <3D6989F7.9ED1948A@zip.com.au>,
> Andrew Morton  <akpm@zip.com.au> wrote:
>>
>>What I'm inclined to do there is to change __page_cache_release()
>>to not attempt to free the page at all.  Just let it sit on the
>>LRU until page reclaim encounters it.  With the anon-free-via-pagevec
>>patch, very, very, very few pages actually get their final release in
>>__page_cache_release() - zero on uniprocessor, I expect.
> 
> If you do this, then I would personally suggest a conceptually different
> approach: make the LRU list count towards the page count.  That will
> _automatically_ result in what you describe - if a page is on the LRU
> list, then "freeing" it will always just decrement the count, and the
> _real_ free comes from walking the LRU list and considering count==1 to
> be trivially freeable.
> 
> That way you don't have to have separate functions for releasing
> different kinds of pages (we've seen how nasty that was from a
> maintainance standpoint already with the "put_page vs
> page_cache_release" thing).
> 
> Ehh? 

If every structure locks before removing its reference (ie before testing and/or
removing a lru reference we take zone->lru_lock, for slabs take cachep->spinlock
etc)  Its a bit of an audit task to make sure the various locks are taken (and
documented) though.

By leting the actual free be lazy as Linus suggests things should simplify nicely.

comments,
Ed Tomlinson
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2002-09-09  5:10 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-08-28 22:11 slablru for 2.5.32-mm1 Ed Tomlinson
  -- strict thread matches above, loose matches on Subject: below --
2002-09-06  4:07 Craig Kulesa
2002-09-06  4:24 ` Robert Love
2002-09-08 21:43   ` Daniel Phillips
2002-09-09  4:36     ` Robert Love
2002-09-09  5:10       ` Daniel Phillips
2002-09-06  4:38 ` Andrew Morton
2002-09-06 11:39   ` Ed Tomlinson
2002-09-06 18:57     ` Craig Kulesa
2002-08-26 22:09 MM patches against 2.5.31 Ed Tomlinson
2002-08-26 23:58 ` Andrew Morton
2002-08-28 17:06   ` slablru for 2.5.32-mm1 Ed Tomlinson
2002-08-28 21:24     ` Andrew Morton
2002-08-28 22:23       ` Rik van Riel
2002-09-02  5:26     ` Andrew Morton
2002-09-02 15:00       ` Ed Tomlinson
2002-09-02 18:35         ` Andrew Morton
2002-09-02 19:09           ` Ed Tomlinson
2002-09-02 19:51             ` Andrew Morton
2002-09-02  6:50     ` Andrew Morton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox