On Wednesday 28 September 2005 17:54, Jeff Dike wrote:
> On Wed, Sep 28, 2005 at 02:14:32PM +0200, Blaisorblade wrote:
> > Very, very nice.
> > Let's hope for the better, but next time the debug should be done
> > *before* merging, ok? Even because, for instance, if (say) the patch was
> > ready f
On Wed, Sep 28, 2005 at 02:14:32PM +0200, Blaisorblade wrote:
> Very, very nice.
>
> What about the early removal of the request from the queue, before being sure
> we can complete it (sorry for not reading carefully everything below, I'm
> going to have lunch and afterwards back to study).
I t
On Tuesday 27 September 2005 20:12, Jeff Dike wrote:
> Attached is my current set of I/O patches. It's significantly different,
> and simpler, than my previous set.
> Now, there is no sleeping while running the queue, so the spinlock is never
> dropped, and all of the extra synchronization is gon
Attached is my current set of I/O patches. It's significantly different,
and simpler, than my previous set.
Now, there is no sleeping while running the queue, so the spinlock is never
dropped, and all of the extra synchronization is gone.
do_ubd_handler runs the queue until it's empty, or the ho
On Wednesday 21 September 2005 22:45, Jeff Dike wrote:
> On Wed, Sep 21, 2005 at 09:06:38PM +0200, Blaisorblade wrote:
> > The block layer is supposed to merge as far as possible overlapping
> > writes, that's reasonable, but not dependable. Say it gets the
> > overlapping request *after* it sent t
On Wed, Sep 21, 2005 at 09:06:38PM +0200, Blaisorblade wrote:
> The block layer is supposed to merge as far as possible overlapping writes,
> that's reasonable, but not dependable. Say it gets the overlapping request
> *after* it sent the first one - we'll see both. Also, this is trivially true
On Wednesday 21 September 2005 20:04, Jeff Dike wrote:
> On Wed, Sep 21, 2005 at 05:49:43PM +0200, Blaisorblade wrote:
[...]
> > Don't think it's reasonable to expect this. I think that filesystems like
> > ext2 will never produce write barriers - they are needed for journaled
> > FS's.
> I though
On Wed, Sep 21, 2005 at 05:49:43PM +0200, Blaisorblade wrote:
> Since you're going to possibly sleep, it's better to allow kmalloc to sleep
> in
> first place!
WRONG! The first request in line can't sleep, that's the whole point.
If it does, the system can deadlock. Subsequent requests can sl
On Tuesday 20 September 2005 21:06, Jeff Dike wrote:
> On Tue, Sep 20, 2005 at 02:01:11PM +0200, Blaisorblade wrote:
> > Hmm, this kind of thing is exactly the one for which mempool's were
> > created - have you looked at whether using them (which can be used for
> > atomic purposes) would be bette
On Tue, Sep 20, 2005 at 02:01:11PM +0200, Blaisorblade wrote:
> Hmm, this kind of thing is exactly the one for which mempool's were created -
> have you looked at whether using them (which can be used for atomic purposes)
> would be better?
Yeah, that would be worth looking into.
> I've not looke
On Sunday 18 September 2005 00:45, Jeff Dike wrote:
> I've spent some time working on the ubd and AIO problems that have cropped
> up recently. Patches are attached - a critical look at them would be
> appreciated.
>
> I'm going to start with a problem that hasn't exactly cropped up, and move
> on
I've spent some time working on the ubd and AIO problems that have cropped up
recently. Patches are attached - a critical look at them would be appreciated.
I'm going to start with a problem that hasn't exactly cropped up, and move on
to the other ones from there.
That is that the ubd driver mu
12 matches
Mail list logo
