From: "Sukrit.Bhatnagar@sony.com" <Sukrit.Bhatnagar@sony.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Pavel Machek <pavel@ucw.cz>,
Christian Brauner <brauner@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: RE: [PATCH 2/2] mm: swap: print starting physical block offset in swapon
Date: Mon, 27 May 2024 11:02:04 +0000 [thread overview]
Message-ID: <TYAPR01MB40483619A52F712D9265D4EAF6F02@TYAPR01MB4048.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <20240522145637.GV25518@frogsfrogsfrogs>
Hi Darrick,
On 2024-05-22 23:56, Darrick Wong wrote:
> On Wed, May 22, 2024 at 04:46:58PM +0900, Sukrit Bhatnagar wrote:
>> When a swapfile is created for hibernation purposes, we always need
>> the starting physical block offset, which is usually determined using
>> userspace commands such as filefrag.
>
> If you always need this value, then shouldn't it be exported via sysfs
> or somewhere so that you can always get to it? The kernel ringbuffer
> can overwrite log messages, swapfiles can get disabled, etc.
I agree on using appropriate kernel interfaces instead of kernel log.
>> It would be good to have that value printed when we do swapon and get
>> that value directly from dmesg.
>>
>> Signed-off-by: Sukrit Bhatnagar <Sukrit.Bhatnagar@sony.com>
>> ---
>> mm/swapfile.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>> diff --git a/mm/swapfile.c b/mm/swapfile.c
>> index f6ca215fb92f..53c9187d5fbe 100644
>> --- a/mm/swapfile.c
>> +++ b/mm/swapfile.c
>> @@ -3264,8 +3264,9 @@ SYSCALL_DEFINE2(swapon, const char __user *, specialfile, int, swap_flags)
>> (swap_flags & SWAP_FLAG_PRIO_MASK) >> SWAP_FLAG_PRIO_SHIFT;
>> enable_swap_info(p, prio, swap_map, cluster_info);
>> - pr_info("Adding %uk swap on %s. Priority:%d extents:%d across:%lluk %s%s%s%s\n",
>> + pr_info("Adding %uk swap on %s. Priority:%d extents:%d start:%llu across:%lluk %s%s%s%s\n",
>> K(p->pages), name->name, p->prio, nr_extents,
>> + (unsigned long long)first_se(p)->start_block,
>
> Last time I looked, start_block was in units of PAGE_SIZE, despite
> add_swap_extent confusingly (ab)using the sector_t type. Wherever you
> end up reporting this value, it ought to be converted to something more
> common (like byte offset or 512b-block offset).
I could not find any swap-related entries in the sysfs, but there is
/proc/swaps which shows the enabled swaps in a table.
A column for this start offset could be added there, which as you have
mentioned, should be in a unit such as bytes instead of PAGE_SIZE
blocks.
> Also ... if this is a swap *file* then reporting the path and the
> physical storage device address is not that helpful. Exposing the block
> device major/minor and block device address would be much more useful,
> wouldn't it?
For exposing information about swap file path, I think it wouldn't make
much difference (at least for the hibernate case) as we can always do
the file-path -> bdev-path -> major:minor conversion in userspace.
> (Not that I have any idea what the "suspend process" in the cover letter
> refers to -- suspend and hibernate have been broken on xfs forever...)
By suspend process, I meant the series of steps taken when we trigger
hibernate's suspend-to-disk.
Not the task that started it. (Wrong choice of words, my bad).
--
Sukrit
next prev parent reply other threads:[~2024-05-27 11:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-22 7:46 [PATCH 0/2] Improve dmesg output for swapfile+hibernation Sukrit Bhatnagar
2024-05-22 7:46 ` [PATCH 1/2] iomap: swap: print warning for unaligned swapfile Sukrit Bhatnagar
2024-05-22 18:02 ` Chris Li
2024-05-27 10:54 ` Sukrit.Bhatnagar
2024-05-22 7:46 ` [PATCH 2/2] mm: swap: print starting physical block offset in swapon Sukrit Bhatnagar
2024-05-22 14:56 ` Darrick J. Wong
2024-05-22 14:59 ` Christoph Hellwig
2024-05-27 11:02 ` Sukrit.Bhatnagar [this message]
2024-05-23 19:45 ` [PATCH 0/2] Improve dmesg output for swapfile+hibernation Pavel Machek
2024-05-27 11:06 ` Sukrit.Bhatnagar
2024-05-27 11:20 ` Christoph Hellwig
2024-05-27 12:51 ` Sukrit.Bhatnagar
2024-05-27 12:58 ` Christoph Hellwig
2024-05-31 14:15 ` Sukrit.Bhatnagar
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=TYAPR01MB40483619A52F712D9265D4EAF6F02@TYAPR01MB4048.jpnprd01.prod.outlook.com \
--to=sukrit.bhatnagar@sony.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rafael@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