On Monday 13 August 2007 04:03, Evgeniy Polyakov wrote:
> On Mon, Aug 13, 2007 at 03:12:33AM -0700, Daniel Phillips
([email protected]) wrote:
> > > This is not a very good solution, since it requires all users of
> > > the bios to know how to free it.
> >
> > No, only the specific ->endio needs to know that, which is set by
> > the bio owner, so this knowledge lies in exactly the right place.
> > A small handful of generic endios all with the same destructor are
> > used nearly everywhere.
>
> That is what I meant - there will be no way to just alloc a bio and
> put it, helpers for generic bio sets must be exported and each and
> every bi_end_io() must be changed to check reference counter and they
> must know how they were allocated.
There are fewer non-generic bio allocators than you think.
> Endio callback is of course quite rare and additional atomic
> reading will not kill the system, but why introduce another read?
> It is possible to provide a flag for endio callback that it is last,
> but it still requires to change every single callback - why do we
> want this?
We don't. Struct bio does not need to be shrunk. Jens wanted to talk
about what fields could be eliminated if we wanted to shrink it. It is
about time to let that lie, don't you think?
> So, I'm a bit lost...
>
> You say it is too big
Did not say that.
> and some parts can be removed or combined
True.
> and then that size does not matter.
Also true, backed up by numbers on real systems.
> Last/not-last checks in the code is
> not clear design, so I do not see why it is needed at all if not for
> size shrinking.
Not needed, indeed. Accurate throttling is needed. If the best way to
throttle requires expanding struct bio a little then we should not let
concerns about the cost of an int or two stand in the way. Like Jens,
I am more concerned about the complexity cost, and that is minimized in
my opinion by throttling in the generic code rather than with custom
code in each specialized block driver.
Your patch does throttle in the generic code, great. Next thing is to
be sure that it completely closes the window for reserve leakage, which
is not yet clear.
Regards,
Daniel
-
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]
