[lkml]   [1999]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: andrea buffer code (2.2.9-C.gz)
On Wed, 19 May 1999, Manfred Spraul wrote:

>1 GB memory means 256.000 spinlocks. I think that's overkill regardless
>of the number of CPU's.

So why don't you kill the buffers field before? It could be shared with
the ->inode field just adding one PG bitflag.

Maybe we'll have to drop the mem_map idea instead of start removing bits
from the huge memmap.

>BTW, I think I found a major SMP-race, I've posted it to
>Since your buffer code fixes parts of that problem, I've attached my

I would be glad if you would explain _why_ my new SMP per-pagemap io-async
locking is not yet safe enough according to you.

>I've found one codpath:
>-> ide_end_request(): acquires io_request_lock, clear local interrupts.
>-> calls end_that_request_first()
>-> calls end_buffer_io_async() <<<<<<<<<< calls cli(), needs global sync.

This race can trigger in SMP but _only_ using software raid or a
block-device hardware that uses two different irqs at once (I am not aware
of such one). Normal block devices are protected by luck ;).

The free_async_buffers(bh) called by brw_page is safe because the cli()
will block if there is the ide irq running, and the ide irq will block
until a sti() will be issued by brw_page. So no reuse_list race there (for
the record: the cli() in btw_page is there only to avoid reuse_list races
that I now avoid very more efficiently by using an wmb() in a strategic
place + xchg and a loop with a bogus pointer).

Then there is the race in end_buffer_io_async() that now I handle using
a per-pagemap spinlock.

The race you seen can't happen in a normal ide hardware because the IDE
irq can't reenter itself. It's an issue with soft-raid where I guess the
same brw_page can generate I/O on different blockdevices that are using
different irqs though. I complelty agree that was _bad_ code and that's
why I rewrote the whole locking once I understood what it was doing.

According to me my new buffer code fix your soft-raid SMP race completly.

For the record I released a new buffer-2.2.9-G.gz. Peter Steiner told me
that I could shift the hashfn result of one more bit. I also had the idea
to avoid a subl in the hasfn ;). As last thing I forced the 64 bit code to
use the old hashfn until I'll get with an ack from Peter aboute the right
hashfn-multiplyer for 64 bits (should be the 32bit-one simply shifted left
by 32 bits, but we would lose precision and I know that Peter sometime
doesn't like the exact result, so right now for 64 arch I use the old
hashfn, but I just prepared the code for using BITS_PER_LONG, so I really
only need a tested multiplyer to allow the new hashfn to work well on
64bit too).

Andrea Arcangeli

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.051 / U:10.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site