From: Christoph Rohland <cr@sap.com>
To: Paul <set@pobox.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: VM question (ramfs abuse)
Date: 06 Feb 2001 10:18:33 +0100 [thread overview]
Message-ID: <m3ofwgb4q7.fsf@linux.local> (raw)
In-Reply-To: <20010123205315.A4662@werewolf.able.es> <m3lmrqrspv.fsf@linux.local> <20010203234550.A507@squish> <m3zog2n6ec.fsf@linux.local> <20010205210540.A10316@squish>
In-Reply-To: <20010205210540.A10316@squish>
Hi Paul,
On Mon, 5 Feb 2001, set@pobox.com wrote:
> Christoph Rohland <cr@sap.com>, on Sun Feb 04, 2001 [10:53:26 AM] said:
> @>Paul <set@pobox.com> writes:
> @>> I finally managed to coax the cursor over to mutt and quit it. Then things
> @>> were instantly fine and I could remove 'blob'.
> @>> My question is, why wasnt any swap used during this time? Ramfs
> @>> may not have any backing store?
> @>
> @>Because RAMFS lives in _physical_ ram. Grab my tmpfs patch and you
> @>will have ramfs + swapping and accounting. But set a limit (Mount
> @>option size) to it before doing anything like
> @>'dd if=/dev/zero of=blob' ;-)
> @>
> Dear Christoph;
>
> First, thankyou for the reply. Heh. Meant to send to the list,
> but got only you. Oh well.
> I have been testing tmpfs on 2.4.1. I havent encountered any
> problems, but I have a question. (with a limit, the pathological dd worked
> just fine :) For fun, I did a
> 'time (make dep && make clean && make bzImage)' using 2.2.18, 2.4.1, and
> various fs's as /tmp. (reiser, ext2, ramfs, tmpfs) Both using and not
> using the -pipe gcc option during the build.
> I was somewhat suprised that each time was the same (within, like
> 1/10th of a percent)
You probably have to stress some more since the page cache is _very_
effective on Linux. I can bring down a kernel compile on a 8way
machine with parallel make from ~44 seconds to ~40 seconds which is a
real speedup ;-)
Actually I really doubt a real speed benefit for normal users with
tmpfs but there may be other benefits:
- 'add swap on any device and your tmpfs grows' can be really valuable.
- Automatic cleanup of /tmp on reboot
- No traces of temporary files on backing store may help the crypto
people. (But no if you swap that argument is hosed.)
- ???
There are some people out there which really wanted to have this and
it was a minor task to add the full support to shm fs.
Greetings
Christoph
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
prev parent reply other threads:[~2001-02-06 9:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-23 19:53 swapfs for 2.4.1-pre J . A . Magallon
2001-02-01 21:39 ` [patch] tmpfs for 2.4.1 Christoph Rohland
2001-02-01 23:50 ` H. Peter Anvin
2001-02-02 9:57 ` Christoph Rohland
2001-02-02 20:52 ` J . A . Magallon
2001-02-02 20:55 ` H. Peter Anvin
2001-02-03 0:06 ` J . A . Magallon
2001-02-03 15:02 ` Christoph Rohland
2001-02-03 14:28 ` Christoph Rohland
2001-02-03 20:27 ` H. Peter Anvin
2001-02-03 20:46 ` J . A . Magallon
2001-02-04 9:53 ` Christoph Rohland
2001-02-04 9:18 ` Christoph Rohland
[not found] ` <20010203234550.A507@squish>
[not found] ` <m3zog2n6ec.fsf@linux.local>
[not found] ` <20010205210540.A10316@squish>
2001-02-06 9:18 ` Christoph Rohland [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3ofwgb4q7.fsf@linux.local \
--to=cr@sap.com \
--cc=linux-kernel@vger.kernel.org \
--cc=set@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.