Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Per-entity load tracking
Posted Jan 11, 2013 18:19 UTC (Fri) by mathstuf (subscriber, #69389)
Posted Jan 11, 2013 22:35 UTC (Fri) by man_ls (subscriber, #15091)
Nowadays with 4 GB of RAM and an SLC SSD most of my bottlenecks are gone. Oh, and with CONFIG_PREEMPT, of course.
Posted Jan 12, 2013 8:49 UTC (Sat) by jospoortvliet (subscriber, #33164)
Posted Jan 12, 2013 14:53 UTC (Sat) by hummassa (subscriber, #307)
stalls caused by USB drive copy
Posted Jan 12, 2013 19:29 UTC (Sat) by giraffedata (subscriber, #1954)
Posted Jan 12, 2013 22:01 UTC (Sat) by man_ls (subscriber, #15091)
Posted Jan 12, 2013 23:24 UTC (Sat) by nix (subscriber, #2304)
(It used to be much worse: it used to stall basically all I/O to *any* block device due to, IIRC from vague faded memory, everything sharing a single queue. That's not true anymore. So this has got better, though I can't tell whether I don't see it these days because the problem has improved or because machines just have huge amounts of memory these days...)
Posted Jan 13, 2013 0:14 UTC (Sun) by man_ls (subscriber, #15091)
The solution for the problem you describe should be, as usual, in several places: stop cp from dirtying more pages than it can move to their destination, and make the kernel avoid this behavior in any process. I really don't know how in the general case. To avoid this kind of problem I don't use swap any more, so that a misbehaving process cannot page everything else to disk. I still get severe slowdowns when memory runs out though; I am still trying to figure out how to avoid them.
Posted Jan 13, 2013 0:22 UTC (Sun) by nybble41 (subscriber, #55106)
vm.dirty_bytes = 201326592
This limits total dirty memory to 192MB before the kernel forces processes to work on writing data to disk rather than dirtying new pages. The default is something like 10% of total RAM. It seems to help.
Posted Jan 13, 2013 1:12 UTC (Sun) by cmccabe (guest, #60281)
Posted Jan 13, 2013 1:59 UTC (Sun) by hummassa (subscriber, #307)
Posted Apr 11, 2013 20:28 UTC (Thu) by serzan (subscriber, #8155)
have you tried ionice -c 3? though not sure it'd have much of an impact, if thrashing memory is the cause
Posted Jan 13, 2013 9:32 UTC (Sun) by BlueLightning (subscriber, #38978)
Have you seen this issue recently? I'm sure I read an LWN article a year or two ago where it was described how this issue was tracked down to a change in the I/O buffer window sizing or something similar (and fixed).
Posted Jan 13, 2013 12:56 UTC (Sun) by hummassa (subscriber, #307)
Posted Jan 12, 2013 1:57 UTC (Sat) by butlerm (subscriber, #13312)
Historically speaking, Linux has always prioritized throughput over "smoothness". If you want something resembling soft real time response, you must abstain from using EXT3, set the swappiness to zero, and use a kernel compiled with CONFIG_PREEMPT or something like it, a version not afflicted with the more recent "stable pages" feature.
Posted Jan 12, 2013 19:43 UTC (Sat) by giraffedata (subscriber, #1954)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds