linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luck, Tony" <tony.luck@intel.com>
To: "Guilherme G. Piccoli" <gpiccoli@igalia.com>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"anton@enomsg.org" <anton@enomsg.org>,
	"ccross@android.com" <ccross@android.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Linux-Fsdevel <linux-fsdevel@vger.kernel.org>,
	"Guilherme G. Piccoli" <kernel@gpiccoli.net>
Subject: RE: pstore/ramoops - why only collect a partial dmesg?
Date: Tue, 4 Jan 2022 17:00:57 +0000	[thread overview]
Message-ID: <a361c64213e7474ea39c97f7f7bd26ec@intel.com> (raw)
In-Reply-To: <0ca4c27a-a707-4d36-9689-b09ef715ac67@igalia.com>

> Hi Tony, thanks a lot for your response! It makes sense indeed, but in
> my case, for example, I have a "log_buf_len=4M", but cannot allocate a
> 4M record_size - when I try that, I can only see page_alloc spews and
> pstore/ramoops doesn't work. So, I could allocate 2M and that works
> fine, but I then lose half of my dmesg heh
> Hence my question.
>
> If there's no special reason, I guess would make sense to allow ramoops
> to split the dmesg, what do you think?

Guilherme,

Linux is indeed somewhat reluctant to hand out allocations > 2MB. :-(

Do you really need the whole dmesg in the pstore dump?  The expectation
is that systems run normally for a while. During that time console logs are
saved off to /var/log/messages.

When the system crashes, the last part (the interesting bit!) of the console
log is lost.  The purpose of pstore is to save that last bit.

So while you could add code to ramoops to save multiple 2MB chunks, it
doesn't seem (to me) that it would add much value.

-Tony

  reply	other threads:[~2022-01-04 17:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-29 14:43 pstore/ramoops - why only collect a partial dmesg? Guilherme G. Piccoli
2022-01-03 23:31 ` Luck, Tony
2022-01-04 12:17   ` Guilherme G. Piccoli
2022-01-04 17:00     ` Luck, Tony [this message]
2022-01-04 18:03       ` Guilherme G. Piccoli
2022-01-04 18:46         ` Luck, Tony
2022-01-04 19:36           ` Guilherme G. Piccoli

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=a361c64213e7474ea39c97f7f7bd26ec@intel.com \
    --to=tony.luck@intel.com \
    --cc=anton@enomsg.org \
    --cc=ccross@android.com \
    --cc=gpiccoli@igalia.com \
    --cc=keescook@chromium.org \
    --cc=kernel@gpiccoli.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).