On Sun, 2002-07-28 at 00:01, Buddy Lumpkin wrote:
>> Are you implying that it should be looking for pages to swap out this
whole
>> time to free up more space for filesystem and executable pages purely
based
>> on lru? Have you done testing to prove that this is a better approach
than
>> setting a threshold of when to wake up the lru mechanism?
>Not all the time - when there is pressure to find more pages.
ok, then it turns out that we agree, Solaris does "the right thing" in this
respect.
>> Solaris keeps dirty pages after they have been flushed to their backing
>> store, it's just when the system has to choose something to flush that it
>> preferences filesystem over anonymous and executable, what's wrong with
>> that?
>Many of its pages are both file system and executable. Solaris shares
>read-only pages between the caches and the mappings into process spaces.
>I can understand favouring flushing mapped files because swap is
>generally slower than restoring a file backed mapping
right, solaris share everything!
it maps text, data, etc... MAP_PRIVATE (COW) and uses the segmap to unify
access between read, write and mmaped MAP_SHARED pages so that
only a single page exists for any single filesystem page. You can see proof
of this by writing a little C program and then while it's running modify it
(say it prints for instance changes from "this is a test" to "this xx a
xxxx" ) and overwrite the new file with mmap MAP_SHARED type access or with
write(), the programs output will change on the fly while it's running.
When I differentiate between filesystem pages and executable, I should have
been specific in saying that executable pages almost always have a named
file as thier backing store, but for this discussion executable means that
the page has the execute bit set.
For priority paging they actually warn that standard files that are mmapped
will be incorrectly treated like executables if they have the execute bits
set. This probably happens quite often so it's not perfect.
--Buddy
-
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/
This archive was generated by hypermail 2b29 : Tue Jul 30 2002 - 14:00:27 EST