Re: [dm-devel] Re: [PATCH resubmit] do_mount: reduce stack consumption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Neil Brown <[email protected]> wrote:
>
> On Tuesday November 8, [email protected] wrote:
> > Andrew Morton wrote:
> > > 
> > > More state in the task_strut is a bit sad, but not nearly as sad as deep
> > > recursion in our deepest codepath..
> > > 
> > > Possibly one could do:
> > > 
> > > struct make_request_state {
> > > 	struct bio *bio_list;
> > > 	struct bio **bio_tail;
> > > };
> > > 
> > > and stick a `struct make_request_state *' into the task_struct and actually
> > > allocate the thing on the stack.  That's not much nicer though.
> > 
> > Possibly it could go into struct io_context?
> > 
> 
> My quick reading of the code says that we could have to 
> allocate the struct right there in generic_make_request, and I don't
> think we can be certain that such an allocation will succeed.

With this sort of lifecycle it's more appropriat to allocate the struct on
the stack and to put a pointer to it into task_struct.

> Code that uses io_context can limp along if it doesn't exist.  
> The new generic_make_request needs this bio_list to be present 
> or it cannot do it's job.
> 
> Just how tight are we for space in task_struct?

I don't recall anyone getting outraged about it.

>  It seems to have a
> fair amount of cruft in it.

yup.

> Is it getting close to one-page or something?

1280 bytes on my x86

> Can we just split the less interesting stuff up into a separate
> structure, allocate a separate page for that are fork time, and leave 
> just a pointer in the task_struct?

Something like that, if it becomes a problem.

Probably there are various deporking opportunities in there.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux