| 1 |
Am 06.12.2010 16:58, schrieb Nikos Chantziaras: |
| 2 |
> On 12/06/2010 04:33 PM, Stroller wrote: |
| 3 |
>> |
| 4 |
[...] |
| 5 |
>> |
| 6 |
>> The machine seems much snappier if I return to an interactive session |
| 7 |
>> after leaving it idle for some time, but during DVD rips it is still |
| 8 |
>> unresponsive for tens of seconds at a time. It seems like maybe it |
| 9 |
>> responds quicker than mainline sources, but it's still so slow that |
| 10 |
>> it's both unusable and hard to be sure whether that's the case. |
| 11 |
>> |
| 12 |
|
| 13 |
As a side note: Have you tried using sys-process/latencytop to find the |
| 14 |
exact reason for your latency problem? |
| 15 |
|
| 16 |
>> Will try cgroups this week, perhaps. |
| 17 |
> |
| 18 |
> cgroups will not help with that either. I bet the problem is that the |
| 19 |
> kernel doesn't care about what kind of data it is caching. I came |
| 20 |
> across this on LKML, but no one was interested in a solution. |
| 21 |
> |
| 22 |
> The problem is that the kernel caches all data. Ripping a DVD will |
| 23 |
> consume 4GB cache, and all other data will be thrown out. Throwing that |
| 24 |
> all out again after the rip has finished is an awful lot of I/O load. |
| 25 |
> The smart thing to do would be for the kernel to not cache such stuff |
| 26 |
> (DVD rips, big video files, etc.) But it does. |
| 27 |
> |
| 28 |
> |
| 29 |
|
| 30 |
I fear I start to repeat myself, but I /think/ cgroups could help again. |
| 31 |
The memory subsystem allows you to set hard limits on the amount of |
| 32 |
memory used by a cgroup. This seems to include cache. |
| 33 |
|
| 34 |
Please take a look at [1] and [2]. Both should give you enough |
| 35 |
information to get you started. You should apply memory limits |
| 36 |
explicitly for certain processes/shells - not on a per-default basis as |
| 37 |
the CPU scheduling solution. |
| 38 |
|
| 39 |
Disclaimer: I have never tried this and do not intend to do this. |
| 40 |
|
| 41 |
[1] |
| 42 |
http://www.google.de/url?sa=t&source=web&cd=1&ved=0CBgQFjAA&url=http%3A%2F%2Fwww.linuxfoundation.jp%2Fjp_uploads%2Fseminar20081119%2FCgroupMemcgMaster.pdf&rct=j&q=%2Bcgroup%20%2B%22file%20cache%22&ei=ZFT9TNWtDZS08QOf-vihDA&usg=AFQjCNHd23FsqouJutTc4BAotkM9CUpfMQ&cad=rja |
| 43 |
|
| 44 |
[2] file:///usr/src/linux/Documentation/cgroups/memory.txt |
| 45 |
|
| 46 |
P.S.: We would not have this problem if application designers were more |
| 47 |
careful about i/o and cache performance. If the dvd ripper opened files |
| 48 |
with the option O_DIRECT (as specified in `man 2 open`), the cache would |
| 49 |
stay clean. |
| 50 |
|
| 51 |
Hope this helps, |
| 52 |
Florian Philipp |
Archives