diff options
author | Thomas Schwinge <tschwinge@gnu.org> | 2013-04-07 18:18:44 +0200 |
---|---|---|
committer | Thomas Schwinge <tschwinge@gnu.org> | 2013-04-07 18:18:44 +0200 |
commit | 6c7d45e4631784d0e077e806521a736da6b0266e (patch) | |
tree | f9d3e9ed304e8cdbf72fc77c135781eb49990f6a /open_issues/performance | |
parent | f8ed211a4da23edf469089254b3dace9479bf11f (diff) |
IRC.
Diffstat (limited to 'open_issues/performance')
-rw-r--r-- | open_issues/performance/io_system/read-ahead.mdwn | 42 |
1 files changed, 42 insertions, 0 deletions
diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn index be582e8a..4034e940 100644 --- a/open_issues/performance/io_system/read-ahead.mdwn +++ b/open_issues/performance/io_system/read-ahead.mdwn @@ -2983,3 +2983,45 @@ License|/fdl]]."]]"""]] determine what m_o_ function will be used <mcsim> now default_read calls m_o_ on its own <braunr> ok + + +## IRC, freenode, #hurd, 2013-03-06 + + <mcsim> braunr: hi, regarding memory policies. Should I create separate + policy that will do pageout or VM_ADVICE_SEQUENTIAL is good enough? + <mcsim> braunr: at the moment it is exactly like NORMAL + <braunr> mcsim: i thought you only did pageins + <mcsim> braunr: yes, but I'm doing pageouts now + <braunr> oh + <braunr> i'd prefer you didn't :/ + <braunr> if you want to improve paging, i have a suggestion i believe is a + lot better + <braunr> and we have 3 patches concerning libpager that we need to review, + polish, and merge in + <mcsim> braunr: That's not hard, and I think I know what to do + <braunr> yes i understand that + <braunr> but it may change the interface and conflict with the pending + changes + <mcsim> braunr: What changes? + <braunr> the large store patch, neal's libpager rework patch on top of + which you made your changes, and your changes + <braunr> the idea i have in mind was writeback throttling + +[[hurd/translator/ext2fs]], [[hurd/libpager]]. + + <braunr> i was planning on doing it myself but if you want to work on it, + feel free to + <braunr> it would be a much better improvement at this time than clustered + pageouts + <braunr> (which can then immediately follow + <braunr> ) + <mcsim> braunr: ok + <mcsim> braunr: but this looks much more bigger task for me + <braunr> we'll talk about the strategy i had in mind tomorrow + <braunr> i hope you find it simple enough + <braunr> on the other hand, clustered pageouts are very similar to pageins + <braunr> and we have enough paging related changes to review that adding + another wouldn't be such a problem actually + <mcsim> so, add? + <braunr> if that's what you want to do, ok + <braunr> i'll think about your initial question tomorrow |