From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans Reiser Subject: zam, please discuss this Date: Tue, 22 Jun 2004 19:29:33 -0700 Message-ID: <40D8EB0D.6050109@namesys.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------010704060305050909020609" Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com List-Id: To: Alexander Zarochentcev Cc: "E. Gryaznova" , ReiserFS List --------------010704060305050909020609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit http://www.namesys.com/intbenchmarks/mongo/04.05.04/256MB.RAM/comparison/smart-8k.noENTD.vs.ENTD/comp-ENTD.vs.noENTD.html --------------010704060305050909020609 Content-Type: text/html; name="www.namesys.com/intbenchmarks/mongo/04.05.04/256MB.RAM/comparison/smart-8k.noENTD.vs.ENTD/comp-ENTD.vs.noENTD.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="www.namesys.com/intbenchmarks/mongo/04.05.04/256MB.RAM/comparison/smart-8k.noENTD.vs.ENTD/comp-ENTD.vs.noENTD.html" Content-Base: "http://www.namesys.com/intbenchmarks/m ongo/04.05.04/256MB.RAM/comparison/ smart-8k.noENTD.vs.ENTD/comp-ENTD.v s.noENTD.html" Content-Location: "http://www.namesys.com/intbenchmarks/m ongo/04.05.04/256MB.RAM/comparison/ smart-8k.noENTD.vs.ENTD/comp-ENTD.v s.noENTD.html"

reiser4 _USE_ENTD (1) vs _USE_ENTD (0)

reiser4
ChangeSet@1.1535, 2004-05-04 16:05:39+04:00
mem total
254476
machine
bones
kernel
2.6.5 #5 SMP Tue May 4 23:31:17 MSD 2004
date
Tue May 4 23:56:49 2004
.config
.
A.INFO_R4=ChangeSet@1.1535, 2004-05-04 16:05:39+04:00
B.INFO_R4=ChangeSet@1.1535, ENTD 0
#0:
REAL_TIME CPU_TIME DF
AB/A AB/A AB/A
CREATE 56.94 1.017 38.15 1.009 1075932 1.000
COPY 179.17 0.932 61.41 1.060 2151692 1.000
READ 151.56 0.773 54.85 1.121 2151692 1.000
STATS 91.28 0.572 24.36 0.971 2151692 1.000
DELETE 180.9 0.836 88.6 1.089 4 1.000
GAMMA=0.0 PHASE_READ=find FILE_SIZE=8192 PHASE_DELETE=rm WRITE_BUFFER=4096 PHASE_APPEND=off FSTYPE=reiser4 NPROC=1 DIR=/mnt1 DEV=/dev/hda6 PHASE_COPY=cp SYNC=off PHASE_OVERWRITE=off PHASE_MODIFY=off BYTES=1024000000 REP_COUNTER=1
Produced by Mongo benchmark suite.
--------------010704060305050909020609-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Zarochentsev Subject: Re: zam, please discuss this Date: Wed, 23 Jun 2004 10:30:50 +0400 Message-ID: <20040623063049.GA5080@backtop.namesys.com> References: <40D8EB0D.6050109@namesys.com> Mime-Version: 1.0 Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com Content-Disposition: inline In-Reply-To: <40D8EB0D.6050109@namesys.com> List-Id: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Hans Reiser Cc: ReiserFS List 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans Reiser Subject: Re: zam, please discuss this Date: Wed, 23 Jun 2004 20:33:46 -0700 Message-ID: <40DA4B9A.8000908@namesys.com> References: <40D8EB0D.6050109@namesys.com> <20040623063049.GA5080@backtop.namesys.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <20040623063049.GA5080@backtop.namesys.com> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Alex Zarochentsev Cc: ReiserFS List 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? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans Reiser Subject: Re: zam, please discuss this Date: Wed, 23 Jun 2004 21:29:48 -0700 Message-ID: <40DA58BC.1060203@namesys.com> References: <40D8EB0D.6050109@namesys.com> <20040623063049.GA5080@backtop.namesys.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <20040623063049.GA5080@backtop.namesys.com> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Alex Zarochentsev Cc: ReiserFS List 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).... From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Beshers Subject: Re: iozone reality check: was zam, please discuss this Date: Wed, 23 Jun 2004 14:03:33 -0400 Message-ID: <40D9C5F5.7010605@comcast.net> References: <40D8EB0D.6050109@namesys.com> <20040623063049.GA5080@backtop.namesys.com> <40DA58BC.1060203@namesys.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <40DA58BC.1060203@namesys.com> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Hans Reiser Cc: ReiserFS List 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).... > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans Reiser Subject: Re: iozone reality check: was zam, please discuss this Date: Wed, 23 Jun 2004 22:13:04 -0700 Message-ID: <40DA62E0.2050803@namesys.com> References: <40D8EB0D.6050109@namesys.com> <20040623063049.GA5080@backtop.namesys.com> <40DA58BC.1060203@namesys.com> <40D9C5F5.7010605@comcast.net> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <40D9C5F5.7010605@comcast.net> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: George Beshers Cc: ReiserFS List 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? From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Beshers Subject: Re: iozone reality check: was zam, please discuss this Date: Wed, 23 Jun 2004 14:36:48 -0400 Message-ID: <40D9CDC0.30503@comcast.net> References: <40D8EB0D.6050109@namesys.com> <20040623063049.GA5080@backtop.namesys.com> <40DA58BC.1060203@namesys.com> <40D9C5F5.7010605@comcast.net> <40DA62E0.2050803@namesys.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <40DA62E0.2050803@namesys.com> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Hans Reiser Cc: ReiserFS List 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). From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans Reiser Subject: Re: iozone reality check: was zam, please discuss this Date: Thu, 24 Jun 2004 00:11:20 -0700 Message-ID: <40DA7E98.1070707@namesys.com> References: <40D8EB0D.6050109@namesys.com> <20040623063049.GA5080@backtop.namesys.com> <40DA58BC.1060203@namesys.com> <40D9C5F5.7010605@comcast.net> <40DA62E0.2050803@namesys.com> <40D9CDC0.30503@comcast.net> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <40D9CDC0.30503@comcast.net> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: George Beshers Cc: ReiserFS List 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.