Avoid always dirtying mapping->flags on O_DIRECT
Subsystems (2)
PATCH 1/1 Avoid always dirtying mapping->flags on O_DIRECT
Hi,
In some testing I ran today, we end up spending 40% of the time in filemap_check_errors(). That smells fishy. Looking further, this is basically what happens:
blkdev_aio_read()
generic_file_aio_read()
filemap_write_and_wait_range()
if (!mapping->nr_pages)
filemap_check_errors()and filemap_check_errors() always attempts two test_and_clear_bit() on the mapping flags, thus dirtying it for every single invocation. The patch below tests each of these bits before clearing them, avoiding this issue. In my test case (4-socket box), performance went from 1.7M IOPS to 4.0M IOPS.
mm/filemap.c +4 -2
@@ -257,9 +257,11 @@ static int filemap_check_errors(struct address_space *mapping) {int ret =0 ;/* Check for outstanding write errors */ -if (test_and_clear_bit (AS_ENOSPC , &mapping->flags)) +if (test_bit (AS_ENOSPC , &mapping->flags) && +test_and_clear_bit (AS_ENOSPC , &mapping->flags)) ret = -ENOSPC ; -if (test_and_clear_bit (AS_EIO , &mapping->flags)) +if (test_bit (AS_EIO , &mapping->flags) && +test_and_clear_bit (AS_EIO , &mapping->flags)) ret = -EIO ;return ret; }
Signature · 7 lines
Jens Axboe -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 12 lines · Jens Axboe
Hi,
In some testing I ran today, we end up spending 40% of the time in
filemap_check_errors(). That smells fishy. Looking further, this is basically what happens:
blkdev_aio_read()generic_file_aio_read() filemap_write_and_wait_range() if (!mapping->nr_pages) filemap_check_errors()
Quoted 5 lines
and
filemap_check_errors()always attempts twotest_and_clear_bit()on the mapping flags, thus dirtying it for every single invocation. The patch below tests each of these bits before clearing them, avoiding this issue. In my test case (4-socket box), performance went from 1.7M IOPS to 4.0M IOPS.
It might help to use the word cacheline somewhere in here. ;-) Out of curiosity, what workload were you running?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
Quoted 14 lines · Jeff Moyer
Quoted 12 lines · Jens Axboe
Hi,
In some testing I ran today, we end up spending 40% of the time in
filemap_check_errors(). That smells fishy. Looking further, this is basically what happens:
blkdev_aio_read()generic_file_aio_read() filemap_write_and_wait_range() if (!mapping->nr_pages) filemap_check_errors()
Quoted 7 lines
Quoted 5 lines
and
filemap_check_errors()always attempts twotest_and_clear_bit()on the mapping flags, thus dirtying it for every single invocation. The patch below tests each of these bits before clearing them, avoiding this issue. In my test case (4-socket box), performance went from 1.7M IOPS to 4.0M IOPS.It might help to use the word cacheline somewhere in here. ;-) Out of
I thought that was self-evident, but yes, I could add that :-)
Quoted 1 line
curiosity, what workload were you running?
Nothing fancy, just some fio jobs that spread over two nodes.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>