On Sun, 29 Jul 2012, Eric Dumazet wrote:
> On Sun, 2012-07-29 at 12:10 +0200, Eric Dumazet wrote:
>
> > You can probably design something needing no more than 4 bytes per cpu,
> > and this thing could use non locked operations as bonus.
> >
> > like the following ...
>
> Coming back from my
On Mon, Jul 30, 2012 at 08:00:19PM -0400, Mikulas Patocka wrote:
>
>
> On Mon, 30 Jul 2012, Paul E. McKenney wrote:
>
> > On Sun, Jul 29, 2012 at 01:13:34AM -0400, Mikulas Patocka wrote:
> > > On Sat, 28 Jul 2012, Eric Dumazet wrote:
> > > > On Sat, 2012-07-28 at 12:41 -0400, Mikulas Patocka
On Mon, Jul 30, 2012 at 08:00:19PM -0400, Mikulas Patocka wrote:
On Mon, 30 Jul 2012, Paul E. McKenney wrote:
On Sun, Jul 29, 2012 at 01:13:34AM -0400, Mikulas Patocka wrote:
On Sat, 28 Jul 2012, Eric Dumazet wrote:
On Sat, 2012-07-28 at 12:41 -0400, Mikulas Patocka wrote:
[ .
On Sun, 29 Jul 2012, Eric Dumazet wrote:
On Sun, 2012-07-29 at 12:10 +0200, Eric Dumazet wrote:
You can probably design something needing no more than 4 bytes per cpu,
and this thing could use non locked operations as bonus.
like the following ...
Coming back from my bike ride,
On Mon, 30 Jul 2012, Paul E. McKenney wrote:
> On Sun, Jul 29, 2012 at 01:13:34AM -0400, Mikulas Patocka wrote:
> > On Sat, 28 Jul 2012, Eric Dumazet wrote:
> > > On Sat, 2012-07-28 at 12:41 -0400, Mikulas Patocka wrote:
>
> [ . . . ]
>
> > > (bdev->bd_block_size should be read exactly once )
On Sun, Jul 29, 2012 at 01:13:34AM -0400, Mikulas Patocka wrote:
> On Sat, 28 Jul 2012, Eric Dumazet wrote:
> > On Sat, 2012-07-28 at 12:41 -0400, Mikulas Patocka wrote:
[ . . . ]
> > (bdev->bd_block_size should be read exactly once )
>
> Rewrite all direct and non-direct io code so that it
On Sun, Jul 29, 2012 at 01:13:34AM -0400, Mikulas Patocka wrote:
On Sat, 28 Jul 2012, Eric Dumazet wrote:
On Sat, 2012-07-28 at 12:41 -0400, Mikulas Patocka wrote:
[ . . . ]
(bdev-bd_block_size should be read exactly once )
Rewrite all direct and non-direct io code so that it reads block
On Mon, 30 Jul 2012, Paul E. McKenney wrote:
On Sun, Jul 29, 2012 at 01:13:34AM -0400, Mikulas Patocka wrote:
On Sat, 28 Jul 2012, Eric Dumazet wrote:
On Sat, 2012-07-28 at 12:41 -0400, Mikulas Patocka wrote:
[ . . . ]
(bdev-bd_block_size should be read exactly once )
Rewrite
On Sun, 2012-07-29 at 12:10 +0200, Eric Dumazet wrote:
> You can probably design something needing no more than 4 bytes per cpu,
> and this thing could use non locked operations as bonus.
>
> like the following ...
Coming back from my bike ride, here is a more polished version with
proper
On Sun, 2012-07-29 at 01:13 -0400, Mikulas Patocka wrote:
> Each cpu should have its own rw semaphore in its cache, so I don't see a
> problem there.
>
> When you change block size, all 4096 rw semaphores are locked for write,
> but changing block size is not a performance sensitive operation.
On Sun, 2012-07-29 at 01:13 -0400, Mikulas Patocka wrote:
Each cpu should have its own rw semaphore in its cache, so I don't see a
problem there.
When you change block size, all 4096 rw semaphores are locked for write,
but changing block size is not a performance sensitive operation.
On Sun, 2012-07-29 at 12:10 +0200, Eric Dumazet wrote:
You can probably design something needing no more than 4 bytes per cpu,
and this thing could use non locked operations as bonus.
like the following ...
Coming back from my bike ride, here is a more polished version with
proper
On Sat, 28 Jul 2012, Eric Dumazet wrote:
> On Sat, 2012-07-28 at 12:41 -0400, Mikulas Patocka wrote:
> > Introduce percpu rw semaphores
> >
> > When many CPUs are locking a rw semaphore for read concurrently, cache
> > line bouncing occurs. When a CPU acquires rw semaphore for read, the
> >
On Sat, 2012-07-28 at 12:41 -0400, Mikulas Patocka wrote:
> Introduce percpu rw semaphores
>
> When many CPUs are locking a rw semaphore for read concurrently, cache
> line bouncing occurs. When a CPU acquires rw semaphore for read, the
> CPU writes to the cache line holding the semaphore.
Introduce percpu rw semaphores
When many CPUs are locking a rw semaphore for read concurrently, cache
line bouncing occurs. When a CPU acquires rw semaphore for read, the
CPU writes to the cache line holding the semaphore. Consequently, the
cache line is being moved between CPUs and this slows
Introduce percpu rw semaphores
When many CPUs are locking a rw semaphore for read concurrently, cache
line bouncing occurs. When a CPU acquires rw semaphore for read, the
CPU writes to the cache line holding the semaphore. Consequently, the
cache line is being moved between CPUs and this slows
On Sat, 2012-07-28 at 12:41 -0400, Mikulas Patocka wrote:
Introduce percpu rw semaphores
When many CPUs are locking a rw semaphore for read concurrently, cache
line bouncing occurs. When a CPU acquires rw semaphore for read, the
CPU writes to the cache line holding the semaphore.
On Sat, 28 Jul 2012, Eric Dumazet wrote:
On Sat, 2012-07-28 at 12:41 -0400, Mikulas Patocka wrote:
Introduce percpu rw semaphores
When many CPUs are locking a rw semaphore for read concurrently, cache
line bouncing occurs. When a CPU acquires rw semaphore for read, the
CPU writes to
18 matches
Mail list logo
