zam, please discuss this

zam, please discuss this

[Hans Reiser]

[-- Attachment #1: Type: text/plain, Size: 123 bytes --]


http://www.namesys.com/intbenchmarks/mongo/04.05.04/256MB.RAM/comparison/smart-8k.noENTD.vs.ENTD/comp-ENTD.vs.noENTD.html

[-- Attachment #2: www.namesys.com/intbenchmarks/mongo/04.05.04/256MB.RAM/comparison/smart-8k.noENTD.vs.ENTD/comp-ENTD.vs.noENTD.html --]
[-- Type: text/html, Size: 4690 bytes --]

Re: zam, please discuss this

[Alex Zarochentsev]

On Tue, Jun 22, 2004 at 07:29:33PM -0700, Hans Reiser wrote:
> 
> http://www.namesys.com/intbenchmarks/mongo/04.05.04/256MB.RAM/comparison/smart-8k.noENTD.vs.ENTD/comp-ENTD.vs.noENTD.html

Because direct page reclaiming (when a thread which needs memory does 
try_to_relase_page() by itself) is better then indirect one (through
ENTD or whatever page reclaiming daemon).  It is why Linux uses direct
page reclaiming not indirect.

-- 
Alex.

PS. Those results are old.

Re: zam, please discuss this

[Hans Reiser]

Alex Zarochentsev wrote:

>On Tue, Jun 22, 2004 at 07:29:33PM -0700, Hans Reiser wrote:
>  
>
>>http://www.namesys.com/intbenchmarks/mongo/04.05.04/256MB.RAM/comparison/smart-8k.noENTD.vs.ENTD/comp-ENTD.vs.noENTD.html
>>    
>>
>
>Because direct page reclaiming (when a thread which needs memory does 
>try_to_relase_page() by itself) is better then indirect one (through
>ENTD or whatever page reclaiming daemon).  It is why Linux uses direct
>page reclaiming not indirect.
>
>  
>
I don't understand this statement.  Did you employ the algorithm I asked 
you to, with it throttling on every Nth page instead of every page?

Re: zam, please discuss this

[Hans Reiser]

Alex Zarochentsev wrote:

>On Tue, Jun 22, 2004 at 07:29:33PM -0700, Hans Reiser wrote:
>  
>
>>http://www.namesys.com/intbenchmarks/mongo/04.05.04/256MB.RAM/comparison/smart-8k.noENTD.vs.ENTD/comp-ENTD.vs.noENTD.html
>>    
>>
>
>Because direct page reclaiming (when a thread which needs memory does 
>try_to_relase_page() by itself) is better then indirect one (through
>ENTD or whatever page reclaiming daemon).  It is why Linux uses direct
>page reclaiming not indirect.
>
>  
>
I apologize to zam, I meant to only cc this to reiserfs-dev. 

 I think this performance loss can be overcome, and needs to be overcome 
so we can eliminate emergency flush and get good iozone results.  I 
should note though that Andrew Morton thinks iozone is a benchmark that 
does things that no application does (dirtying massive amounts of mmap'd 
pages).  I am curious as to whether the sysadmins on the list would 
agree with that (Andrew may be right)....

Re: iozone reality check: was zam, please discuss this

[George Beshers]

Caveat: I have not looked at the iozone test so this is purely in response
to Han's description.

The examples I know of are apps that allocate an mmap'd area for garbage
collection: ocaml, sml-nj, and I believe ghc (Haskell) do this.  While these
systems usually have generational GCs at some point major collections
happen and then I *believe* that you will see lots of dirty pages.

Note: the 'believe' is based on some experiments on an SGI ccNuma
system with profiling tools---I was looking at local access issues and
noticed the pattern of changes to flag objects as "marked" in a mark/sweep
collector.  I then tried ocaml as an experiment and saw something
similar.


I have not look at Boehm conservative collector in some time, but if
memory serves me correctly it uses separate arrays to hold the bits;
using mmap is an option---I don't know if it is in common use.

Some 18-20 months ago I spent some time looking at the Java GC
but I don't remember its using mmap() and I no longer have the source
available.

George Beshers



Hans Reiser wrote:

> Alex Zarochentsev wrote:
>
>> On Tue, Jun 22, 2004 at 07:29:33PM -0700, Hans Reiser wrote:
>>  
>>
>>> http://www.namesys.com/intbenchmarks/mongo/04.05.04/256MB.RAM/comparison/smart-8k.noENTD.vs.ENTD/comp-ENTD.vs.noENTD.html 
>>>
>>>   
>>
>>
>> Because direct page reclaiming (when a thread which needs memory does 
>> try_to_relase_page() by itself) is better then indirect one (through
>> ENTD or whatever page reclaiming daemon).  It is why Linux uses direct
>> page reclaiming not indirect.
>>
>>  
>>
> I apologize to zam, I meant to only cc this to reiserfs-dev.
> I think this performance loss can be overcome, and needs to be 
> overcome so we can eliminate emergency flush and get good iozone 
> results.  I should note though that Andrew Morton thinks iozone is a 
> benchmark that does things that no application does (dirtying massive 
> amounts of mmap'd pages).  I am curious as to whether the sysadmins on 
> the list would agree with that (Andrew may be right)....
>

Re: iozone reality check: was zam, please discuss this

[Hans Reiser]

George Beshers wrote:

>
> Caveat: I have not looked at the iozone test so this is purely in 
> response
> to Han's description.
>
> The examples I know of are apps that allocate an mmap'd area for garbage
> collection: ocaml, sml-nj, and I believe ghc (Haskell) do this.  While 
> these
> systems usually have generational GCs at some point major collections
> happen and then I *believe* that you will see lots of dirty pages.
>
> Note: the 'believe' is based on some experiments on an SGI ccNuma
> system with profiling tools---I was looking at local access issues and
> noticed the pattern of changes to flag objects as "marked" in a 
> mark/sweep
> collector.  I then tried ocaml as an experiment and saw something
> similar.
>
>
> I have not look at Boehm conservative collector in some time, but if
> memory serves me correctly it uses separate arrays to hold the bits;
> using mmap is an option---I don't know if it is in common use.
>
> Some 18-20 months ago I spent some time looking at the Java GC
> but I don't remember its using mmap() and I no longer have the source
> available.
>
> George Besher

When you say lots, do you mean close to or more than physical ram?

Re: iozone reality check: was zam, please discuss this

[George Beshers]

Hans Reiser wrote:

>
> When you say lots, do you mean close to or more than physical ram?
>
My recollection is that it was on the order of 70% of physical ram; there
was significant other activity on the system so it was getting flushed to
disk some of the time, but I was not actually measuring that.  I was looking
at cache-coherency across processor nodes and noticed that most of
the pages in the mmap'd area were touched (modified).

Re: iozone reality check: was zam, please discuss this

[Hans Reiser]

George Beshers wrote:

>
>
> Hans Reiser wrote:
>
>>
>> When you say lots, do you mean close to or more than physical ram?
>>
> My recollection is that it was on the order of 70% of physical ram; there
> was significant other activity on the system so it was getting flushed to
> disk some of the time, but I was not actually measuring that.  I was 
> looking
> at cache-coherency across processor nodes and noticed that most of
> the pages in the mmap'd area were touched (modified).
>
>
>
>
>
Ok, this qualifies as an app where it matters.