Parallel Startup for KDE.

[Roger Larsson]

On Wednesday 01 October 2003 21.29, Stefan Heimers wrote:
> I had some rather strange ideas about those matters today, some are
> similar to what others proposed.
>
> 1) Make two kde-init-skripts, one loading disk intense tasks, one
> loading cpu intense tasks.
>
> + This will avoid concurrent disk seeks from different programs,
>    while keeping the cpu busy all the time.
> - Might not be practical because of dependencies

Interesting approach. An alternative could be to start CPU intense tasks niced 
(with lower priority) - renice them to normal later.
But does KDE have any CPU intense tasks??? linking (all, but somewhat handled 
by kdeinit), sorting (kmail, konqueror), rendering - inkluding animation and 
java script processing (konqueror). But are there any tasks that are CPU 
intense all the time? Most of the time? Quite some time during startup?

>
>
> 2) Inside multithreaded programs, try to arrange new threads so they are
> startet right before disk access from other threads. This would fill
> the wait time during disk seek, even if programs are started
> sequentially.

It is probably easier to let the new thread do the IO.
But it is generally hard to see where IO is done.
Is the IO done when creating a class/plugin/... or when using it?
If I use this class how do I know if it will use a subclass that will need to 
do IO?

Example: How should the konqueror history/favicon data be loaded?
1) In a dataserver (cache) before konqueror is started?
2) At konqueror startup before window is shown?
3) In a thread of its own while drawing?
4) When first needed by the user?

But they have their own problems:
1) Will add time to initial desktop start, space waste if never started.
2) Konqueror will look slow to start.
3) Might interfere with other concurrent operations. In addition the drawing 
time is usually short compared to any disk IO.
4) Konqueror will look slow to react to keyboard/mouse input.

>
> 3) Load all config data from a single file in order to make disk cache
> effective and reduce head repositioning. I know a quick&dirty trick:
> Create a small filesystem on a file and mount it through a loopback
> device to /usr/share/kde, put symlinks for /etc/kde3,
> /usr/share/applnk,... pointing into /usr/share/kde

Then the filesystem has to be sequential in nature to read it all in one
stroke, but that could waste a lot of bandwidth if you only need a part of it.
But it would help locality - somewhat... (there is no guarantee that the
host filesystem will place it in one place sequential)

There is a tool that can check if a file is sequential or not (attached), run 
as root:

for file in ~roger/.kde/share/config/*; do
	echo $file; ./show_file_blocks $file
done

Most files are only one page long, but the worst offenders are...
(each new line is a new sequential part)

/home/roger/.kde/share/config/katesyntaxhighlightingrc
0-0: 12355115-12355115 (1)
1-1: 12355270-12355270 (1)
2-8: 12355272-12355278 (7)
9-11: 12355280-12355282 (3)
12-12: 12356431-12356431 (1)
13-13: 12358293-12358293 (1)
14-14: 12358761-12358761 (1)
15-15: 12358771-12358771 (1)
16-17: 12501573-12501574 (2)
18-19: 12571180-12571181 (2)

/home/roger/.kde/share/config/kmailrc
0-8: 12373287-12373295 (9)
9-11: 12373297-12373299 (3)
12-14: 12373301-12373303 (3)
15-15: 12453955-12453955 (1)
16-16: 12458523-12458523 (1)

Probably the applications appends/rewrites the file.

Another example (Knoppix ISO file)

./show_file_blocks /var/downloaded/Linux/KNOPPIX_V3.1-2003-01-20-EN.iso
- uninteresting long list -
292 lines
165 lines with (1024) consecutive 
 28 with  (1)
 68 with (2) to (9)
  9 with (10) to (19)
...

>
> Question: If you mount a filesytem from a file in stead of a partition,
> what happens to disk cache? Is the file containing the filesystem
> cached? Or the single files inside the filesystem? Or both?

Zipping .kde/share/config/ could be another option (accessing using KIO 
slaves?)


/RogerL

-- 
Roger Larsson
Skellefteå
Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: show_file_blocks.c
Type: text/x-csrc
Size: 1749 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-optimize/attachments/20031002/7c54e0e7/show_file_blocks.bin