Messages in this thread | | | Date | Wed, 19 May 1999 19:08:27 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: 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 >linux-kernel@vger. >Since your buffer code fixes parts of that problem, I've attached my >mail.
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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |