On Wed, 28 Nov 2012, Jeff Chua wrote:
> On Wed, Nov 28, 2012 at 12:01 PM, Mikulas Patocka wrote:
> > block_dev: don't take the write lock if block size doesn't change
> >
> > Taking the write lock has a big performance impact on the whole system
> > (because of synchronize_sched_expedited).
On Wed, Nov 28, 2012 at 12:01 PM, Mikulas Patocka wrote:
> block_dev: don't take the write lock if block size doesn't change
>
> Taking the write lock has a big performance impact on the whole system
> (because of synchronize_sched_expedited). This patch avoids taking the
> write lock if the
On Wed, Nov 28, 2012 at 12:01 PM, Mikulas Patocka mpato...@redhat.com wrote:
block_dev: don't take the write lock if block size doesn't change
Taking the write lock has a big performance impact on the whole system
(because of synchronize_sched_expedited). This patch avoids taking the
write
On Wed, 28 Nov 2012, Jeff Chua wrote:
On Wed, Nov 28, 2012 at 12:01 PM, Mikulas Patocka mpato...@redhat.com wrote:
block_dev: don't take the write lock if block size doesn't change
Taking the write lock has a big performance impact on the whole system
(because of
block_dev: don't take the write lock if block size doesn't change
Taking the write lock has a big performance impact on the whole system
(because of synchronize_sched_expedited). This patch avoids taking the
write lock if the block size doesn't change (i.e. when mounting
filesystem with block
block_dev: don't take the write lock if block size doesn't change
Taking the write lock has a big performance impact on the whole system
(because of synchronize_sched_expedited). This patch avoids taking the
write lock if the block size doesn't change (i.e. when mounting
filesystem with block
6 matches
Mail list logo