All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Wang" <00107082@163.com>
To: "Suren Baghdasaryan" <surenb@google.com>
Cc: "Tim Chen" <tim.c.chen@linux.intel.com>,
	kent.overstreet@linux.dev, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v2 2/2] alloc_tag: keep codetag iterator active between read() calls
Date: Sat, 10 May 2025 11:58:04 +0800 (CST)	[thread overview]
Message-ID: <7bb65ee6.129c.196b857cdb3.Coremail.00107082@163.com> (raw)
In-Reply-To: <CAJuCfpHuYHJh6yM+na0WLi3Lb910m73Xth8N3ZBnJKpAW5Qxww@mail.gmail.com>



At 2025-05-10 11:30:50, "Suren Baghdasaryan" <surenb@google.com> wrote:
>On Fri, May 9, 2025 at 8:10 PM David Wang <00107082@163.com> wrote:
>>
>>
>> At 2025-05-10 05:15:43, "Suren Baghdasaryan" <surenb@google.com> wrote:
>> >On Fri, May 9, 2025 at 1:46 PM Suren Baghdasaryan <surenb@google.com> wrote:
>> >>
>> >> On Fri, May 9, 2025 at 12:46 PM Tim Chen <tim.c.chen@linux.intel.com> wrote:
>> >> >
>> >> > On Fri, 2025-05-09 at 12:36 -0700, Suren Baghdasaryan wrote:
>> >> > > On Fri, May 9, 2025 at 11:33 AM Tim Chen <tim.c.chen@linux.intel.com> wrote:
>> >> > > >
>> >> > > > On Sat, 2025-05-10 at 01:39 +0800, David Wang wrote:
>> >> > > > >
>> >> > > > >
>> >> > > > > Signed-off-by: David Wang <00107082@163.com>
>> >> > >
>> >> > > Acked-by: Suren Baghdasaryan <surenb@google.com>
>> >> > >
>> >> > > > > ---
>> >> > > > >  lib/alloc_tag.c | 29 ++++++++++-------------------
>> >> > > > >  1 file changed, 10 insertions(+), 19 deletions(-)
>> >> > > > >
>> >> > > > > diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c
>> >> > > > > index 25ecc1334b67..fdd5887769a6 100644
>> >> > > > > --- a/lib/alloc_tag.c
>> >> > > > > +++ b/lib/alloc_tag.c
>> >> > > > > @@ -45,21 +45,16 @@ struct allocinfo_private {
>> >> > > > >  static void *allocinfo_start(struct seq_file *m, loff_t *pos)
>> >> > > > >  {
>> >> > > > >       struct allocinfo_private *priv;
>> >> > > > > -     struct codetag *ct;
>> >> > > > >       loff_t node = *pos;
>> >> > > > >
>> >> > > > > -     priv = kzalloc(sizeof(*priv), GFP_KERNEL);
>> >> > > > > -     m->private = priv;
>> >> > > > > -     if (!priv)
>> >> > > > > -             return NULL;
>> >> > > > > -
>> >> > > > > -     priv->print_header = (node == 0);
>> >> > > > > +     priv = (struct allocinfo_private *)m->private;
>> >> > > > >       codetag_lock_module_list(alloc_tag_cttype, true);
>> >> > > > > -     priv->iter = codetag_get_ct_iter(alloc_tag_cttype);
>> >> > > > > -     while ((ct = codetag_next_ct(&priv->iter)) != NULL && node)
>> >> > > > > -             node--;
>> >> > > > > -
>> >> > > > > -     return ct ? priv : NULL;
>> >> > > > > +     if (node == 0) {
>> >> > > > > +             priv->print_header = true;
>> >> > > > > +             priv->iter = codetag_get_ct_iter(alloc_tag_cttype);
>> >> > > > > +             codetag_next_ct(&priv->iter);
>> >> > > > > +     }
>> >> > > >
>> >> > > > Do you need to skip print header when *pos != 0? i.e add
>> >> > >
>> >> > > Technically not needed since proc_create_seq_private() allocates
>> >> > > seq->private using kzalloc(), so the initial value of
>> >> > > priv->print_header is always false.
>> >> >
>> >> > But we'll start with first call to allocinfo_start() with *pos == 0,
>> >>
>> >> Usually but not always if we do lseek() to a non-zero position beforehand.
>> >
>> >Actually, this change will break the lseek() case. We can't always
>> >assume that we start reading from *pos == 0. Current patch will fail
>> >to initialize priv if we start reading with *pos != 0.
>> >priv->iter should be tracking current position and allocinfo_start()
>> >should detect a mismatch between *pos and iter->pos and re-walk the
>> >tags if there was a position change.
>>
>> seq_file works line by line,  I think even if it support lseek, seq_file would still start with line #0,
>> since seq_file have on clue the byte size for each line.
>>
>> I will check the code,  make some tests and update later.
>
>Ah, yes. You are correct.
>seq_lseek() will traverse restarting from 0:
>https://elixir.bootlin.com/linux/v6.14.6/source/fs/seq_file.c#L323.
>Position jumps are similarly handled with traversal from 0:
>https://elixir.bootlin.com/linux/v6.14.6/source/fs/seq_file.c#L194.
>

Actually I was expecting EOPNOTSUPP when lseek on seq files, surprised to see it works...... :)

If seq_file somehow skips start(0),  then nothing would be displayed since 
priv->iter.ct would be 0 and `return priv->iter.ct ? priv : NULL;` would return NULL;
But I think that case  would be  seq_file's bug,   starting with 0 is kind of protocol promised by seq_file. 


>>

>>
>> >
>> >>
>> >> > then print_header will be initialized to true.
>> >>
>> >> After the first call to allocinfo_show() print_header will be reset
>> >> back to false.
>> >>
>> >> > Will there be subsequent calls of allocinfo_start() with *pos !=0,
>> >> > but priv->print_header stays at 0?
>> >>
>> >> Yes, there will be subsequent calls to allocinfo_start() with *pos !=0
>> >> and priv->print_header=false, which is what we want, right? We want to
>> >> print the header only at the beginning of the file (node == 0).
>> >>
>> >> >
>> >> > Tim
>> >> > >
>> >> > > >
>> >> > > >         } else {
>> >> > > >                 priv->print_header = false;
>> >> > > >         }
>> >> > > >
>> >> > > > Tim
>> >> > > >
>> >> > > > > +     return priv->iter.ct ? priv : NULL;
>> >> > > > >  }
>> >> > > > >
>> >> > > >
>> >> >

  reply	other threads:[~2025-05-10  3:58 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-07 17:55 [PATCH] alloc_tag: avoid mem alloc and iter reset when reading allocinfo David Wang
2025-05-07 18:19 ` David Wang
2025-05-07 23:42   ` [PATCH] " Suren Baghdasaryan
2025-05-08  0:01     ` Kent Overstreet
2025-05-08  3:06       ` David Wang
2025-05-08  3:31         ` Kent Overstreet
2025-05-08  3:35           ` David Wang
2025-05-08  4:07             ` Kent Overstreet
2025-05-08  5:51               ` David Wang
2025-05-08 13:33                 ` Kent Overstreet
2025-05-08 16:24                   ` David Wang
2025-05-08 16:34                     ` Kent Overstreet
2025-05-08 16:58                       ` David Wang
2025-05-08 17:17                         ` David Wang
2025-05-08 17:26                           ` Kent Overstreet
2025-05-08  2:24     ` David Wang
2025-05-07 23:36 ` Suren Baghdasaryan
2025-05-08  3:10   ` David Wang
2025-05-08 15:32   ` David Wang
2025-05-08 21:41     ` Suren Baghdasaryan
2025-05-09  5:51 ` [PATCH 1/2] alloc_tag: add timestamp to codetag iterator David Wang
2025-05-09 16:10   ` Suren Baghdasaryan
2025-05-09 16:16     ` David Wang
2025-05-09  5:53 ` [PATCH 2/2] alloc_tag: keep codetag iterator cross read() calls David Wang
2025-05-09 17:34   ` Suren Baghdasaryan
2025-05-09 17:45     ` David Wang
2025-05-09 17:38 ` [PATCH v2 1/2] alloc_tag: add sequence number for module and iterator David Wang
2025-05-09 19:25   ` Suren Baghdasaryan
2025-06-09  6:42     ` [PATCH v3 " David Wang
2025-06-09 16:41       ` Suren Baghdasaryan
2025-05-09 17:39 ` [PATCH v2 2/2] alloc_tag: keep codetag iterator active between read() calls David Wang
2025-05-09 18:33   ` Tim Chen
2025-05-09 19:36     ` Suren Baghdasaryan
2025-05-09 19:46       ` Tim Chen
2025-05-09 20:46         ` Suren Baghdasaryan
2025-05-09 21:15           ` Suren Baghdasaryan
2025-05-10  3:10             ` David Wang
2025-05-10  3:30               ` Suren Baghdasaryan
2025-05-10  3:58                 ` David Wang [this message]
2025-05-10  4:03                   ` Suren Baghdasaryan
2025-06-09  6:44                     ` [PATCH v3 2/2] alloc_tag: keep codetag iterator active between read() David Wang
2025-06-10 16:22                       ` Suren Baghdasaryan
2025-05-10  3:35         ` [PATCH v2 2/2] alloc_tag: keep codetag iterator active between read() calls David Wang
2025-05-10  3:25     ` David Wang

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=7bb65ee6.129c.196b857cdb3.Coremail.00107082@163.com \
    --to=00107082@163.com \
    --cc=akpm@linux-foundation.org \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=surenb@google.com \
    --cc=tim.c.chen@linux.intel.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.