lkml.org 
[lkml]   [2006]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: msync() behaviour broken for MS_ASYNC, revert patch?
Linus Torvalds <torvalds@osdl.org> wrote:
>
>
>
> On Fri, 10 Feb 2006, Oliver Neukum wrote:
> >
> > Am Freitag, 10. Februar 2006 20:05 schrieb Linus Torvalds:
> > > So we may have different expectations, because we've seen different
> > > patterns. Me, I've seen the "events are huge, and you stagger them", so
> > > that the previous event has time to flow out to disk while you generate
> > > the next one. There, MS_ASYNC starting IO is _wrong_, because the scale of
> > > the event is just huge, so trying to push it through the IO subsystem asap
> > > just makes everything suck.
> >
> > Isn't the benefit of starting writing immediately greater the smaller
> > the area in question? If so, couldn't a heuristic be found to decide whether
> > to initiate IO at once?
>
> Quite possibly. I suspect you could/should take other issues into account
> too (like whether the queue to the device is busy or bdflush is already
> working).
>

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.

The code under balance_dirty_pages() does pay attention to queue congestion
states, already-under-writeback pages and such things, but it could be
better, I guess. Starting some writeback earlier if the queue is deemed to
be idle could work.

(Hi, Stephen)
-
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/

\
 
 \ /
  Last update: 2006-02-10 21:14    [W:0.061 / U:1.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site