[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tmpfs status

From: Thomas Schwinge
Subject: Re: tmpfs status
Date: Mon, 26 Mar 2012 22:24:55 +0200
User-agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.3.1 (i486-pc-linux-gnu)


On Mon, 26 Mar 2012 21:31:45 +0300, Maksym Planeta <mcsim.planeta@gmail.com> 
> I'm currently working on getting tmpfs work on the Hurd. I already asked
> on IRC to make or suggest some test for tmpfs. Last time Thomas Schwinge 
> suggested me to compile packages and thanks to that a found some bugs. 
> Now they are seems to be fixed, [...]


> I also made some performance tests. First was measuring time of working 
> command "apt-get source elinks". Approximately half time of working of 
> this command takes extracting files from archive. Second test was
> measuring time for command "dpkg-buildpackage -b -nc". I've tested 
> tmpfs, ext2fs that mounted on ramdisk and usual ext2fs. Results are in 
> following table:

Did you reboot the machine after every test?

>                     apt-get          dpkg-buildpackage  
> ramfs+ext2fs          22s                 50m
> ext2fs                32s                 46m
> tmpfs                 16s                 47m
> So, although tmpfs has advantage in speed, it doesn't give much gain in
> task, like compiling packages.

OK, the apt-get task shows how the results get better if a) the disk I/O
layer is removed (ext2fs -> ramfs+ext2fs), and b) one indirection (and
RPC) layer is removed (ramfs+ext2fs -> tmpfs).  As for the
dpkg-buildpackage: my understanding is that once the data is cached in
RAM, there's not much difference anymore.  No idea off-hand why ext2fs is
the fastest, though.

> 1. 
> http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=mplaneta/tmpfs/master 

Someone to review the patches...  :-/


Attachment: pgpZJQGME5yL9.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]