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.
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? It seems to have a
fair amount of cruft in it.
Is it getting close to one-page or something?
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?
NeilBrown
-
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]
