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 [email protected] https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
