lkml.org 
[lkml]   [2002]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: More on O_STREAMING (goodby read pauses)

On 2002.10.10 Mark Mielke wrote:
>On Thu, Oct 10, 2002 at 04:39:27PM +0200, J.A. Magallon wrote:
>> On 2002.10.10 Mark Mielke wrote:
>> >I assume the stall is not 'while pages are sent to disk', but rather
>> >until kswapd gets around to freeing enough pages to allow memory to
>> >fill again. The stall is due to the pages being fully analyzed to
>> >determine which ones should go, and which ones shouldn't. O_STREAMING
>> >removes the pages ahead of time, so no analysis is ever required.
>> I can _hear_ the disk activity when the stall happens, so selecting what
>> to drop is fast, but then you have to write it...
>
>I don't think this is right. Prove me wrong by explaining how kswapd works,
>but if a page isn't dirty, there is no need to write it out to disk.
>

You suppose it is a page of code ? What about data that programs malloc() ???
You can also send data memory to swap. If you do not write it on disk,
how do you recover it ???

>My (perhaps incorrect) assumption is that kswapd prefers to swap on clean
>pages over dirty pages. If your pages are mostly clean, there is nothing
>to write to disk the clear majority of the time.
>
>Clean read-only pages should *never* be written to swap. They can be re-read
>from their source.

That is your fault, <read-only>. Pages maped read-only are those from
binary executables or shared libraries, but, again, what about data ?

>
>I _think_ what you are seeing is that kswapd is not cleaning pages out
>fast enough, which means that *other* tasks executing need to have their
>*swapped out* pages *read* from disk. I.e. the churning you hear is probably
>mostly reads - not writes.
>

I look at gnome system monitor graph for mem. I start with a tiny amount of
used memory. Start the 1Gb read without O_STREAM, the blue area in monitor
starts to grow linearly in time, stars (*) from the reader appear at a
given rate, and as soon as it touches the top limit the stars stop, the disk
begins to thrash, and swap space used grows. After a 2-4 seconds, the stars
go again with the same rate. Tell me what is this but swapper writing pages,
and reading the new pages for my giga.

With O_STREAM, the 'blue bar' does not move from its place, and star rate
(ie, read rate from disk), stays uniform.


--
J.A. Magallon <jamagallon@able.es> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.1 (Cooker) for i586
Linux 2.4.20-pre10-jam1 (gcc 3.2 (Mandrake Linux 9.0 3.2-2mdk))
-
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: 2005-03-22 13:29    [W:0.049 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site