From: viro@parcelfarce.linux.theplanet.co.uk
To: Chris Friesen <cfriesen@nortelnetworks.com>
Cc: "Kevin P. Fleming" <kpfleming@backtobasicsmgmt.com>,
Andrey Borzenkov <arvidjaar@mail.ru>,
Jeff Garzik <jgarzik@pobox.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Is initramfs freed after kernel is booted?
Date: Mon, 17 Nov 2003 17:47:20 +0000 [thread overview]
Message-ID: <20031117174720.GY24159@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <20031117172557.GX24159@parcelfarce.linux.theplanet.co.uk>
On Mon, Nov 17, 2003 at 05:25:57PM +0000, viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Mon, Nov 17, 2003 at 11:06:48AM -0500, Chris Friesen wrote:
> > Kevin P. Fleming wrote:
> >
> > >There is no pivot_root happening here; the kernel creates a ramfs and
> > >mounts it on / (as rootfs), then unpacks the initramfs cpio archive into
> > >it. After doing a few more steps, it overmounts the real root onto /,
> > >making the rootfs filesystem invisible. It is not freed in the current
> > >kernels.
> >
> > Anyone know why it overmounts rather than pivots?
>
> Because amount of extra code you lose that way takes more memory than
> empty roots takes.
Grr... My apologies - I shouldn't have posted before getting some coffee...
The short version of the story:
* empty rootfs consists of 1 struct superblock, 1 struct dentry and
1 struct inode. That's less than 1Kb.
* work with the mount tree is much easier if you know that its root
is always there and always the same.
* if we start playing with changing the absolute root of mount tree,
we will have to add rather unpleasant code in pivot_root() et.al. and that
extra code will definitely take more than 1Kb.
In other words, it's simply not worth the trouble. Unlike the situation with
initrd, memory is reclaimed when you do unlink() or rmdir() on rootfs. So
rm(1) will do nicely...
next prev parent reply other threads:[~2003-11-17 17:47 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-16 17:09 Andrey Borzenkov
2003-11-16 19:51 ` Jeff Garzik
2003-11-17 14:39 ` Chris Friesen
2003-11-17 15:36 ` "Andrey Borzenkov"
2003-11-17 15:39 ` Chris Friesen
2003-11-17 15:46 ` Jeff Garzik
2003-11-17 18:32 ` Bryan O'Sullivan
2003-11-17 15:47 ` Kevin P. Fleming
2003-11-17 16:06 ` Chris Friesen
2003-11-17 16:25 ` Erik Mouw
2003-11-17 17:25 ` viro
2003-11-17 17:47 ` viro [this message]
2003-11-17 17:50 ` Chris Friesen
2003-11-17 18:03 ` viro
2003-11-17 18:33 ` Andrey Borzenkov
2003-11-17 19:15 ` viro
2003-11-19 14:19 ` Olaf Hering
2003-11-19 15:07 ` Hannes Reinecke
2003-11-25 18:26 ` Manuel Estrada Sainz
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=20031117174720.GY24159@parcelfarce.linux.theplanet.co.uk \
--to=viro@parcelfarce.linux.theplanet.co.uk \
--cc=arvidjaar@mail.ru \
--cc=cfriesen@nortelnetworks.com \
--cc=jgarzik@pobox.com \
--cc=kpfleming@backtobasicsmgmt.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®