On Thursday July 24, a.p.zijlstra@chello.nl wrote:
Restrict objects from reserve slabs (ALLOC_NO_WATERMARKS) to allocation
contexts that are entitled to it. This is done to ensure reserve pages don't
leak out and get consumed.
This looks good (we are still missing slob though, aren't we :-( )
quoted hunk
@@ -1526,7 +1540,7 @@ load_freelist:
object = c->page->freelist;
if (unlikely(!object))
goto another_slab;
- if (unlikely(SLABDEBUG && PageSlubDebug(c->page)))
+ if (unlikely(PageSlubDebug(c->page) || c->reserve))
goto debug;
This looks suspiciously like debugging code that you have left in.
Is it??
quoted hunk
@@ -265,7 +267,8 @@ struct array_cache {
unsigned int avail;
unsigned int limit;
unsigned int batchcount;
- unsigned int touched;
+ unsigned int touched:1,
+ reserve:1;
This sort of thing always worries me.
It is a per-cpu data structure so you won't get SMP races corrupting
fields. But you do get read-modify-write in place of simple updates.
I guess it's not a problem.. But it worries me :-)
NeilBrown