Messages in this thread | | | Date | Sat, 23 Feb 2002 13:42:50 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] only irq-safe atomic ops |
| |
Stephen Lord wrote: > > ... > >If we needed exact reader-accounting for the number of dirty pages in the > >machine then we'd need a ton of new locking in fun places like __free_pte(), > >and that still doesn't account for pages which are only pte-dirty, and it's > >not obvious what we'd do with reader-exact dirty page info anyway? > > > > > You do want to avoid a leak in one direction or the other, the os would > start to think it > had lots of dirty pages, but not be able to find them, or think there is > no shortage > when in fact there was.
Oh absolutely. Even a one-page-per-hour leak would be catastrophic.
But there is a problem. If CPUA is always setting pages dirty, and CPUB is always setting them clean, CPUA's counter will eventually overflow, and CPUB's will underflow. Drat.
One fix for this would be special-case over- and under-flow handling:
if (TestSetPageDirty(page)) { preempt_disable(); nr_dirty_pages[smp_processor_id()]++; if (nr_dirty_pages[smp_processor_id()] > 2,000,000) { fit_it_up(); } preempt_enable(); }
void fix_it_up() { spin_lock(&global_counter_lock); global_counter += 1,000,000; nr_dirty_pages[smp_processor_id()] -= 1,000,000; spin_unlock(&global_counter_lock); }
int approx_total_dirty_pages() { int ret;
spin_lock(&global_counter_lock); ret = global_counter; for (all cpus) { ret += nr_dirty_pages[cpu]; } spin_unlock(&global_counter_lock); return ret; }
Or something like that.
Then again, maybe the underflows and overflows don't matter, because the sum of all counters is always correct. Unless there's a counter roll-over during the summation. No. Even then it's OK.
hmmm.
- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |