mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dave Young <dyoung@redhat.com>
To: Rob Landley <rob@landley.net>
Cc: akpm@linux-foundation.org, gregkh@linuxfoundation.org,
	grant.likely@secretlab.ca, sebastian.capella@linaro.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] use initmpfs even if there's root= cmdline
Date: Thu, 19 Dec 2013 10:35:24 +0800	[thread overview]
Message-ID: <20131219023524.GB2070@darkstar.nay.redhat.com> (raw)
In-Reply-To: <52B1E0A2.2030202@landley.net>

On Wed, Dec 18, 2013 at 11:51:30AM -0600, Rob Landley wrote:
> 
> 
> On 12/12/13 20:38, Dave Young wrote:
> >On 12/12/13 at 05:25pm, Dave Young wrote:
> >>
> >>Current code use ramfs instead of tmpfs for stub when root= defined.
> >>
> >>But for real use case with initramfs, usually there's like cmdline like
> >>root=UUID=$UUID the root dev is the real device. For that case we have
> >>no way to use initmpfs, thus this patch removes the limitation so tmpfs
> >>can benefit more people.
> 
> The reason I did that was if you specify a root= then you don't want
> to _stay_ on rootfs. You specify root= so either the kernel does
> switch_root for you, or so rootfs does a swich_root at the end.
> 
> The point of initmpfs is that when rootfs _is_ the "real" root
> device, it can benefit from being tmpfs. When you're just goign to
> switch to a different root device, tmpfs doesn't make much
> difference.

The reason make sense to most of users. Thanks for the info.
For Fedora kdump initramfs there's different requirement though, we do the
vmcore capturing in ramfs with root=, the root= is not necessay in most of
the cases because we will reboot immediately after vmcore capturing finish.
There's one potential exception is that we could switch to real root in
case of capturing failure. Another thing is we use dracut to create initramfs
and dracut has a limitation that root= is a must-have param.

> 
> >Discussed with Vivek Goyal about the kdump use case, I missed one thing that
> >tmpfs has default size limit though we can tune it.
> >
> >So I will think more about it, will address this later, please ignore this
> >patch.
> 
> I have a vague todo item of feeding rootflags= through to initmpfs,
> but that's really intended to specify flags for root=. There isn't
> really an existing command line option to specify initramfs flags
> because ramfs doesn't care.
> 
> It was one of those "only parse rootflags= for initmpfs when there's
> no root=" vs "create a new rdrootflags= ala rdinit= even though
> that's a subtly wrong name these days..." and it went on the todo
> list because neither approach was obviously superior.
> 
> Happy to take suggestions and whip up a patch if this is
> inconveniencing somebody. :)

It would be great that initmpfs can use the whole memory on demand by default at
the same time we can avoid the deadlock mentioned about OOM handler.

For this purpose no need for extra flags? For other flags maybe "initmpfsflags="?

Thanks
Dave

  reply	other threads:[~2013-12-19  2:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-12  9:25 Dave Young
2013-12-12 11:49 ` Dave Young
2013-12-13  2:38 ` Dave Young
2013-12-18 17:51   ` Rob Landley
2013-12-19  2:35     ` Dave Young [this message]
2013-12-23  4:49       ` Rob Landley
2013-12-23  6:43         ` Dave Young

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=20131219023524.GB2070@darkstar.nay.redhat.com \
    --to=dyoung@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=grant.likely@secretlab.ca \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rob@landley.net \
    --cc=sebastian.capella@linaro.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®