On Thursday August 17, [EMAIL PROTECTED] wrote: > Andrew Morton wrote: > > Daniel Phillips <[EMAIL PROTECTED]> wrote: > >>What happened to the case where we just fill memory full of dirty file > >>pages backed by a remote disk? > > > > Processes which are dirtying those pages throttle at > > /proc/sys/vm/dirty_ratio% of memory dirty. So it is not possible to "fill" > > memory with dirty pages. If the amount of physical memory which is dirty > > exceeds 40%: bug. > > Hi Andrew, > > So we make 400 MB of a 1 GB system unavailable for write caching just to > get around the network receive starvation issue?
No. We make it unavailable for write caching so it is available for other important things like cached clean pages and executables etc. You have to start throttling some where or you get very bad behaviour. 40% seems a good number, but it is tunable. The fact that it helps with receive starvation is just s bonus. > > What happens if some in kernel user grabs 68% of kernel memory to do some > very important thing, does this starvation avoidance scheme still work? That is a very good question. Is memlocked memory throttled against dirty pages, and does it decrease the space available to the 40% calculation? I don't know. I guess I could look at the code... get_dirty_limits in page_writeback caps 'dirty_ratio' (40 by default, hence the 40%) at unmapped_ratio/2. So yes. If 68% is mapped and locked (I assume that it the situation you are referring to) that leaves 32% unlocked, so the 40% above is reduced to 16% and you should still have 160Meg of breathing space. NeilBrown - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
