Re: msync() behaviour broken for MS_ASYNC, revert patch?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Linus Torvalds <[email protected]> wrote:
>
> 
> 
> On Fri, 10 Feb 2006, Andrew Morton wrote:
> > 
> > Yes, it would make sense to run balance_dirty_pages_ratelimited() inside
> > msync_pte_range().  So pdflush will get poked if we hit
> > background_dirty_ratio threshold, or we go into caller-initiated writeout
> > if we hit dirty_ratio.
> > 
> > But it's not completely trivial, because I don't think we want to be doing
> > blocking writeback with mmap_sem held.
> 
> Why not just do it once, at the end? 
> 

We could, sort-of.

balance_dirty_pages() is quite CPU-intensive (hence the presence of
balance_dirty_pages_ratelimited()).

balance_dirty_pages_ratelimited() expects to be called once per
page-dirtying.  

- We can't use balance_dirty_pages() because workloads which do lots of
  teeny msyncs would chew lots of CPU.

- We can't use balance_dirty_pages_ratelimited() because it thinks only a
  single page was dirtied.

So the thing to do is to change msync to keep track of how many pages were
dirtied, then at the end call

balance_dirty_pages_ratelimited_new_improved_api(mapping, nr_pages_dirtied).

Except an msync can cover multiple mappings, so we'd need to pop the lock
in the top-level loop, run the above for each VMA.  Not rocket-science, I
guess.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux