All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Mukesh Ojha <quic_mojha@quicinc.com>,
	linux-kernel@vger.kernel.org, senozhatsky@chromium.org,
	rostedt@goodmis.org
Subject: Re: [PATCH v3] printk: ringbuffer: Improve prb_next_seq() performance
Date: Wed, 26 Jan 2022 18:08:12 +0100	[thread overview]
Message-ID: <YfF//E5hUNJKqg2g@alley> (raw)
In-Reply-To: <87tudxfafq.fsf@jogness.linutronix.de>

On Fri 2022-01-21 15:14:41, John Ogness wrote:
> Hi Mukesh,
> 
> Thanks for pushing this. I think it got lost somewhere. I have a couple
> very minor non-functional change requests.

Yes, thanks for pushing this. I have somehow lost this patch on my radar.

> On 2022-01-21, Mukesh Ojha <quic_mojha@quicinc.com> wrote:
> > From: Petr Mladek <pmladek@suse.com>
> >
> > prb_next_seq() always iterates from the first known sequence number.
> > In the worst case, it might loop 8k times for 256kB buffer,
> > 15k times for 512kB buffer, and 64k times for 2MB buffer.
> >
> > It was reported that pooling and reading using syslog interface
> 
>                        ^^^^^^^ polling
> 
> > might occupy 50% of CPU.
> >
> > Speedup the search by storing @id of the last finalized descriptor.
> >
> > The loop is still needed because the @id is stored and read in the best
> > effort way. An atomic variable is used to keep the @id consistent.
> > But the stores and reads are not serialized against each other.
> > The descriptor could get reused in the meantime. The related sequence
> > number will be used only when it is still valid.
> >
> > An invalid value should be read _only_ when there is a flood of messages
> > and the ringbuffer is rapidly reused. The performance is the least
> > problem in this case.
> >
> > Link: https://lore.kernel.org/lkml/YXlddJxLh77DKfIO@alley/T/#m43062e8b2a17f8dbc8c6ccdb8851fb0dbaabbb14
> > Reported-by: Chunlei Wang <chunlei.wang@mediatek.com>
> > Signed-off-by: Petr Mladek <pmladek@suse.com>
> > Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
> > ---
> > Changes against v2:
> >   Added the hunk suggested by John
> >
> Petr can probably just make the changes when committing. I am not
> requesting a v4.
> 
> @Petr: Feel free to add:
> 
> Reviewed-by: John Ogness <john.ogness@linutronix.de>

I made the changes suggested by John. Also I have reverted few more
formatting changes. The result is basically v2 + the hunk suggested
by John.

The patch is committed in printk/linux.git, branch
rework/fast-next-seq. I am going to queue it for 5.18.

Best Regards,
Petr

      parent reply	other threads:[~2022-01-26 17:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-21 13:06 [PATCH v3] printk: ringbuffer: Improve prb_next_seq() performance Mukesh Ojha
2022-01-21 14:08 ` John Ogness
2022-01-26  6:55   ` Mukesh Ojha
2022-01-26 17:08   ` Petr Mladek [this message]

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=YfF//E5hUNJKqg2g@alley \
    --to=pmladek@suse.com \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_mojha@quicinc.com \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.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 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.