Issue 57679 - Startup: reduce rdb file iowait time
Summary: Startup: reduce rdb file iowait time
Status: CLOSED FIXED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: 680m137
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 3.1
Assignee: matthias.huetsch
QA Contact: issues@framework
URL:
Keywords: oooqa, performance
Depends on:
Blocks:
 
Reported: 2005-11-10 14:41 UTC by mmeeks
Modified: 2010-02-22 14:59 UTC (History)
10 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
pagein-common improvements (2.90 KB, text/plain)
2008-01-31 15:25 UTC, mmeeks
no flags Details
before changes (168.28 KB, image/png)
2008-01-31 15:29 UTC, mmeeks
no flags Details
after changes (137.19 KB, image/png)
2008-01-31 15:30 UTC, mmeeks
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description mmeeks 2005-11-10 14:41:53 UTC
So - since we know services.rdb & types.rdb are bad cold-start seek offendors, I
added this patch as a quick fix:

It also preloads the *ui* libraries - which, of course may not be used but ...

--- desktop/source/pagein/makefile.mk	8 Sep 2005 17:44:11 -0000	1.8
+++ desktop/source/pagein/makefile.mk	10 Nov 2005 12:51:35 -0000
@@ -81,23 +81,27 @@ UPDDLLPOST=$(UPD)$(DLLPOSTFIX)$(DLLPOST)
 
 $(MISC)$/$(TARGET)-calc : makefile.mk
 	@+echo Making: $@
-	@-+echo $(DLLPRE)sc$(UPDDLLPOST)  >  $@
-	@-+echo $(DLLPRE)svx$(UPDDLLPOST) >> $@
+	@-+echo $(DLLPRE)sc$(UPDDLLPOST)   >  $@
+	@-+echo $(DLLPRE)scui$(UPDDLLPOST) >>  $@
+	@-+echo $(DLLPRE)svx$(UPDDLLPOST)  >> $@
 
 $(MISC)$/$(TARGET)-draw : makefile.mk
 	@+echo Making: $@
-	@-+echo $(DLLPRE)sd$(UPDDLLPOST)  >  $@
-	@-+echo $(DLLPRE)svx$(UPDDLLPOST) >> $@
+	@-+echo $(DLLPRE)sd$(UPDDLLPOST)   >  $@
+	@-+echo $(DLLPRE)sdui$(UPDDLLPOST) >>  $@
+	@-+echo $(DLLPRE)svx$(UPDDLLPOST)  >> $@
 
 $(MISC)$/$(TARGET)-impress : makefile.mk
 	@+echo Making: $@
-	@-+echo $(DLLPRE)sd$(UPDDLLPOST)  >  $@
-	@-+echo $(DLLPRE)svx$(UPDDLLPOST) >> $@
+	@-+echo $(DLLPRE)sd$(UPDDLLPOST)   >  $@
+	@-+echo $(DLLPRE)sdui$(UPDDLLPOST) >>  $@
+	@-+echo $(DLLPRE)svx$(UPDDLLPOST)  >> $@
 
 $(MISC)$/$(TARGET)-writer : makefile.mk
 	@+echo Making: $@
-	@-+echo $(DLLPRE)sw$(UPDDLLPOST)  >  $@
-	@-+echo $(DLLPRE)svx$(UPDDLLPOST) >> $@
+	@-+echo $(DLLPRE)sw$(UPDDLLPOST)   >  $@
+	@-+echo $(DLLPRE)swui$(UPDDLLPOST) >>  $@
+	@-+echo $(DLLPRE)svx$(UPDDLLPOST)  >> $@
 
 # sorted in reverse load order (ld.so.1)
 $(MISC)$/$(TARGET)-common : makefile.mk
@@ -139,4 +143,6 @@ $(MISC)$/$(TARGET)-common : makefile.mk
 	@-+echo $(DLLPRE)vcl$(UPDDLLPOST)   >> $@
 	@-+echo $(DLLPRE)tk$(UPDDLLPOST)    >> $@
 	@-+echo $(DLLPRE)svt$(UPDDLLPOST)   >> $@
+	@-+echo types.rdb                   >> $@
+	@-+echo services.rdb                >> $@
 	@-+echo soffice.bin                 >> $@
Comment 1 thorsten.martens 2005-11-18 10:18:13 UTC
TM->MH: Please have a look.
Comment 2 Martin Hollmichel 2005-11-24 20:42:18 UTC
reassign
Comment 3 Stephan Bergmann 2006-01-19 14:48:55 UTC
Oops, this somehow got lost.  Matthias, what do you think about it?
Comment 4 mmeeks 2006-01-19 16:11:27 UTC
of course, this works best with the 2nd start speedups in i#60696# ;-)
Comment 5 stx123 2006-05-11 14:43:43 UTC
Matthias, are you going to comment on the PATCH?
Comment 6 matthias.huetsch 2006-10-18 16:00:58 UTC
mhu->mmeeks: IIRC, we talked about this privately already, but leaving this
officially uncommented is bad, of course.

First of all, you're right in that the 2 rdb files take a considerable amount of
(iowait) time during cold startup. Also, the only cure that I know of, is to get
them sequentially "paged in".

But, as we discussed, we can do better than this patch. In an upcoming revision
of the "store" code, this sequential page-in will be a built-in feature of the
store code (this is still work in progress, though, and not yet scheduled for a
particular release).

The rest of your patch, i.e. page-in of the UI libraries conflicts with the work
that has been done (for 2.0.0) to factor them out of their respective
application libraries. Moreover, they are simply not needed during startup, and
thus should not be page'd-in.

I'm keeping this issue to justify the "store" changes mentioned above.
Comment 7 mmeeks 2006-10-18 17:44:06 UTC
un-marking patch then to save you getting grief :-)

Interesting - I thought the UI libraries were in fact in use on startup, but now
I see they're not, of course that makes perfect sense.

FWIW - recent studies show that using 'madvise' is almost pointless on Linux,
but 'fadvise' works rather well [ just for when you get to chose a system call
in that code ;-], certainly a kernel bug to workaround there.

Thanks.
Comment 8 matthias.huetsch 2006-10-18 17:56:41 UTC
Adapting issue summary ("pagein hack..." => "Startup: reduce rdb file iowait
time") and issue type ("PATCH" => Performance "DEFECT") to better reflect what
problem this issue really addresses.
Comment 9 matthias.huetsch 2006-10-18 18:00:46 UTC
mhu->mmeeks: So, our updates to this issue just had a "mid-air collision" :-)
Of course you're right in marking it as ENHANCEMENT, but I'm willing to accept
it as a Performance defect (like all those other startup improvements).

Anyway, thanks for always providing a patch for the issues that you raise,
Matthias
Comment 10 mmeeks 2008-01-31 15:25:22 UTC
Created attachment 51294 [details]
pagein-common improvements
Comment 11 mmeeks 2008-01-31 15:29:16 UTC
The attached patch fixes a few sillies that have crept into pagein-common over
the years eg. we upgraded ICU:

+.INCLUDE .IGNORE : icuversion.mk
 
-ICUDLLPOST=$(DLLPOST).26
+ICUDLLPOST=$(DLLPOST).$(ICU_MAJOR)$(ICU_MINOR)

etc.

I also substantially expand the scope of things we pagein on startup - this
according to iogrind has a pleasant effect on cold start time.

I attach a couple of photographs of the iogrind output before/after - the
timings are in my blog; it's interesting that the configmgr doesn't show up
nearly as heavily as I would have expected - on the other hand, it's quite
possible that this is some failure of simulation etc. :-)
Comment 12 mmeeks 2008-01-31 15:29:56 UTC
Created attachment 51295 [details]
before changes
Comment 13 mmeeks 2008-01-31 15:30:14 UTC
Created attachment 51296 [details]
after changes
Comment 14 utomo99 2008-02-01 05:04:49 UTC
many people complains about OOo which is Slow. 
This patch can reduce the complains. 

I hope we can integrate it soon. as this patch already exist.

Thanks
Comment 15 mmeeks 2008-02-04 09:19:02 UTC
Caolan - you might want this ? :-)
Comment 16 Martin Hollmichel 2008-04-11 10:07:11 UTC
set target 3.0
Comment 17 Martin Hollmichel 2008-08-28 17:39:29 UTC
is this issue still valid, who's responsible for making any progress ?
Comment 18 matthias.huetsch 2008-08-28 17:46:53 UTC
mhu->mh: Well, this is mine, and it's going to be added to cws mhu17 sometime
soon. Changing an issue's type back to PATCH (with new attachements) after
agreeing on another fix does really help, but I will factor out the proposed
pagein-common changes to another issue, as soon as I get to it. And, yes, 3.x is
the better target.
Comment 19 matthias.huetsch 2008-12-08 16:51:02 UTC
Both, the 'store' changes, as well as the 'pagein' changes are now implemented
in cws_src680_mhu17...

Changed target milestone to 3.1 (estimated).
Comment 20 carsten.driesner 2009-03-06 09:41:46 UTC
cd: Made a code review with MHU. Verified.
Comment 21 thorsten.ziehm 2010-02-22 14:59:30 UTC
This issue is closed automatically. It should be fixed in a version with is
available for longer than half a year (OOo 3.1). If you think this issue isn't
fixed in the current version (OOo 3.2) please reopen it. But then please pay
attention about the field 'target milestone'.
The closure was approved by the Release Status Meeting at 22nd of February 2010
and it is based on the issue handling guideline for fixed/verified issues  :
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues