Re: [PATCH 2/2] move slab pages to the lru, for 2.5.27

[Ed Tomlinson <tomlins@cam.org>]

On July 23, 2002 12:36 am, William Lee Irwin III wrote:
> On Mon, 22 Jul 2002, William Lee Irwin III wrote:
> >> The pte_chain mempool was ridiculously huge and the use of mempool for
> >> this at all was in error.
>
> On Mon, Jul 22, 2002 at 03:36:33PM -0700, Craig Kulesa wrote:
> > That's what I thoguht too -- but Steven tried making the pool 1/4th the
> > size and it still failed.  OTOH, he tried 2.5.27-rmap, which uses the
> > *same mempool patch* and he had no problem with the monster 128KB
> > allocation.  Maybe it was all luck. :)  I can't yet see anything in the
> > slablru patch that has anything to do with it...
>
> While waiting for the other machine to boot I tried these out. There
> appear to be bootstrap ordering problems either introduced by or
> exposed by this patch:

I would vote for ordering.  The slab init code was changed to initialize 
new fields...   Allocating memory for slabs is another story.  They depend on
the lru lists and the pagemap_lru_lock being setup...   Has this happened 
when slab storage is initialized?  If not a call to do this in the slab init logic 
would fix things.  It could also be fixed using this fragment (slab.c):

+       /*
+        * We want the pagemap_lru_lock, in UP spin locks to not
+        * protect us in interrupt context...  In SMP they do but,
+        * optimizating for speed, we process if we do not get it.
+        */
+       if (!(cachep->flags & SLAB_NO_REAP)) {
+#ifdef CONFIG_SMP
+               locked = spin_trylock(&pagemap_lru_lock);
+#else
+               locked = !in_interrupt() && spin_trylock(&pagemap_lru_lock);
+#endif
+               if (!locked && !in_interrupt())
+                       goto opps1;

If there is some way to verify that the pagemap_lru_lock is ready.  Note its
fine to just set locked to 0 and proceed - as long as this condition does not
last forever.  Also this code is in a fastpath so efficient is good...

Thoughts?
Ed Tomlinson