Re: [uml-devel] Review needed for ubd fixes

[Blaisorblade <blaisorblade@yahoo.it>]

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 better?

> Yeah, that would be worth looking into.

> > I've not looked at the code, but have you tested that with
> > sleep-inside-spinlock checking enabled?

> > However, ok, you do release spinlocks so you should be safe. However, in
> > your custom allocation routines, you're going to sleep possibly, so why
> > do you use GFP_ATOMIC? There's absolutely no need. If there's a need, you
> > can't take the semaphore afterwards.

> ?

> GFP_ATOMIC doesn't always mean that you're in an interrupt.
> Generally, it means not to sleep in kmalloc.
Yes, but GFP_ATOMIC was needed in first place because we where in an atomic 
section (not for interrupts, but because we were under a spinlock).

> And here, if it fails, 
> I'll use the static buffers.
Since you're going to possibly sleep, it's better to allow kmalloc to sleep in 
first place!

> > These two atomics + one wait queue are very similar to a semaphore, even
> > if not identical. The semaphore value would be submitted - started. The
> > change is that the driver sleep at the first increment of "started"
> > rather than at the last one, but it should be ok. And much less
> > error-prone. If you keep your custom design, you should at least unify
> > the two vars with the difference.

> The wait queue allows the correct thread to be woken up.  If I used a
> semaphore, its value would be the same for all threads, and they would
> all be woken up when that value goes to 0.  With a wait queue, each
> thread has a different value of started, and they wait for submitted
> to catch up to it.
Ok, filtered wait queues. And I also see why you used two atomics rather than 
one. I'll have to think deep about this, though.
> Meanwhile, any other sleeping threads stay 
> sleeping because submitted hasn't caught up to their values of started.
[...]
> I'm concerned about the COW bitmap.  That's something that the upper
> layers know nothing about, so requests could overlap without there
> being barriers between that.

> However, this is an artifact of the implementation, where the section
> of bitmap that will be written out is copied into the aio request when
> it is started.  If I grabbed the bitmap section and set the bits in it
> just before it is written out, then the sequencing stuff might be able
> to just go away.
Is the COW bitmap mmap'ed? Because otherwise we'd need to queue up an 
additional write request, which creates problems.

Btw, msync() allows sync'ing only a specific region, which fsync() doesn't 
allow. Don't know whether we need this really, however (we probably don't do 
it, but we should).

Also, I kept forgetting to mention one thing: Device mapper has the support 
for COW volumes, like we do. E.g. when you create a snapshot, it is not a 
static immutable copy of the original, it's writable too!

Sure, less granular than COW devices, it doesn't copy 512 bytes at a time 
(which may help with performance though), but works on the host too!

I was waiting to let lists know of this after writing a conversion program, 
which I never finished.
> We rely on the block layer to put write barriers 
> between requests with overlapping data.
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.
> 				Jeff

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel