lkml.org 
[lkml]   [2007]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Distributed storage.
Date
On Monday 13 August 2007 04:03, Evgeniy Polyakov wrote:
> On Mon, Aug 13, 2007 at 03:12:33AM -0700, Daniel Phillips
(phillips@phunq.net) 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-08-13 16:47    [W:0.168 / U:0.992 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site