Re: 2.6.8.1-mm2

[Alex Zarochentsev <zam@namesys.com>]

On Fri, Aug 20, 2004 at 12:37:25AM -0700, Hans Reiser wrote:
> Andrew Morton wrote:
> 
> >Hans Reiser <reiser@namesys.com> wrote:
> > 
> >
> >>John Cherry wrote:
> >>
> >>   
> >>
> >>>The new "errors" are from reiser4 code and they all appear to be...
> >>>
> >>>fs/reiser4/reiser4.h:18:2: #error "Please turn 4k stack off"
> >>>
> >>>
> >>>
> >>>     
> >>>
> >>zam, can you or Mr. Demidov work on using kmalloc to reduce stack usage?
> >>
> >>Andrew suggested that for statically sized objects kmalloc is quite fast 
> >>(one instruction I think he said), so my objection to kmallocing a lot 
> >>has faded.
> >>   
> >>
> >
> >err, not that quick - but it's pretty quick.
> >
> >With a kmalloc with a constant size and, preferably, a constant gfp mask
> >we'll jump directly into __cache_alloc() and in the common case we'll pluck
> >an entry directly out of the cpu-local head array:
> >
> >So the kmalloc fastpath is, effectively:
> >
> >	local_irq_save(save_flags);
> >	ac = ac_data(cachep);
> >	if (likely(ac->avail)) {
> >		ac->touched = 1;
> >		objp = ac_entry(ac)[--ac->avail];
> >	}
> >	local_irq_restore(save_flags);
> >	return objp;
> >
> >
> >Not bad...
> >
> >
> > 
> >
> but not trivial.  Sigh.  It means determining whether we can get below 
> 4k without performance loss requires detailed code examination to 
> determine what is using up the stack in practice, and discussion.
> 
> Well, maybe zam has a comment.

yes. there are large objects (reiser4 context, balancing pools, ...) which
reiser4 allocates on stack. we will use kmalloc/slab for them and see how
performance is changed.  not trivial things will be required if those fixes
would not enough.

> 
> Hans

-- 
Alex.