Thread (75 messages) 75 messages, 7 authors, 2007-08-27

Re: Distributed storage.

From: Daniel Phillips <hidden>
Date: 2007-08-13 11:45:09
Also in: linux-fsdevel, lkml

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:
quoted
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help