I've filed this as kern/36169.

Brian.

On 2007.04.18 10:27:47 -0600, Brian de Alwis wrote:
> Summary: a call to msync(2) with flags MS_ASYNC | MS_INVALIDATE
> appears to be done as a synchronous call, and can take >1sec.
> Should it? How can I avoid it?
> 
> I'm packaging up crm114 for pkgsrc: crm114 is a powerful text
> classifier that does particularly well for spam filtering, amongst
> other uses.  (It's in wip/crm114; it's marked as broken for now as
> some of its more esoteric classifiers currently fail the tests,
> though it does compile and work with the usual classifiers.)
> 
> I'm trying to figure out why causes a long sustained disk write of
> a second or more on each spam classification.  ktrace -R reports
> that almost a second is spent in a call to __msync13():
> 
>     0.9941388845 CALL  __msync13(0xbb7df000,0x2dc714,3)
> 
> corresponding to a call in the source:
> 
>     msync (map->addr, map->actual_len, MS_ASYNC | MS_INVALIDATE);
> 
> crm114 does most of its file manipulation by mmaping the files to
> memory and uses the contents as a hash table.  In my case there
> are two spam classification mmaps (sparse files) which are 3,000,084
> bytes each.  So although MS_ASYNC is specified, it appears the sync
> is actually treated as synchronous.  Should it be?  How it be
> avoided? (I'm not sure why the author uses MS_INVALIDATE.)
> 
> Compounding this problem is that the spam processing does this for
> each message processed.
> 
> Brian.
> 
> -- 
>   Brian de Alwis | Software Practices Lab | UBC | http://www.cs.ubc.ca/~bsd/
>       "Amusement to an observing mind is study." - Benjamin Disraeli

-- 
  Brian de Alwis | Software Practices Lab | UBC | http://www.cs.ubc.ca/~bsd/
      "Amusement to an observing mind is study." - Benjamin Disraeli