From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Andrea Parri <parri.andrea@gmail.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Paul McKenney <paulmck@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: state names: vas: Re: [PATCH next v3 6/8] printk: ringbuffer: add finalization/extension support
Date: Wed, 2 Sep 2020 12:52:50 +0200 [thread overview]
Message-ID: <20200902105250.GA15764@alley> (raw)
In-Reply-To: <20200831011058.6286-7-john.ogness@linutronix.de>
On Mon 2020-08-31 03:16:56, John Ogness wrote:
> Add support for extending the newest data block. For this, introduce
> a new finalization state flag (DESC_FINAL_MASK) that denotes when a
> descriptor may not be extended, i.e. is finalized.
> --- a/kernel/printk/printk_ringbuffer.c
> +++ b/kernel/printk/printk_ringbuffer.c
> @@ -49,14 +49,16 @@
> * Descriptors have three states:
> *
> * reserved
> - * A writer is modifying the record.
> + * A writer is modifying the record. Internally represented as either "0"
> + * or "DESC_COMMIT_MASK".
We should explain the difference between the two values. It might be
enough to add something like:
See "Descriptor Finalization" section for more details."
> @@ -79,6 +81,25 @@
> * committed or reusable queried state. This makes it possible that a valid
> * sequence number of the tail is always available.
> *
> + * Descriptor Finalization
> + * ~~~~~~~~~~~~~~~~~~~~~~~
> + * When a writer calls the commit function prb_commit(), the record may still
> + * continue to be in the reserved queried state. In order for that record to
> + * enter into the committed queried state, that record also must be finalized.
> + * A record can be finalized by three different scenarios:
> + *
> + * 1) A writer can finalize its record immediately by calling
> + * prb_final_commit() instead of prb_commit().
> + *
> + * 2) When a new record is reserved and the previous record has been
> + * committed via prb_commit(), that previous record is finalized.
> + *
> + * 3) When a record is committed via prb_commit() and a newer record
> + * already exists, the record being committed is finalized.
> + *
> + * Until a record is finalized (represented by "DESC_FINAL_MASK"), a writer
> + * may "reopen" that record and extend it with more data.
> + *
> * Data Rings
> * ~~~~~~~~~~
> * The two data rings (text and dictionary) function identically. They exist
[...]
> +/*
> + * Attempt to remove the commit flag so that the record can be modified by a
> + * writer again. This is only possible if the descriptor is not yet finalized.
> + *
> + * Note that on success, the queried state did not change. A non-finalized
> + * record (even with the commit flag set) is in the reserved queried state.
> + */
> +static struct prb_desc *desc_reopen_last(struct prb_desc_ring *desc_ring,
> + u32 caller_id, unsigned long *id_out)
> +{
> + unsigned long prev_state_val;
> + enum desc_state d_state;
> + struct prb_desc desc;
> + struct prb_desc *d;
> + unsigned long id;
> +
> + id = atomic_long_read(&desc_ring->head_id);
> +
> + /*
> + * To minimize unnecessarily reopening a descriptor, first check the
> + * descriptor is in the correct state and has a matching caller ID.
> + */
> + d_state = desc_read(desc_ring, id, &desc);
> + if (d_state != desc_reserved ||
> + !(atomic_long_read(&desc.state_var) & DESC_COMMIT_MASK) ||
This looks like a hack. And similar extra check of the bit is needed
also in desc_read(), see
https://lore.kernel.org/r/878sdvq8kd.fsf@jogness.linutronix.de
I has been actually getting less and less happy with the inconsistency
between names of the bits and states.
Sigh, you will hate me because this would mean a bigger change.
IMHO, it would be much cleaner and help with long-term maintainability
when we do the following two changes:
First, define 5 desc_states, something like:
enum desc_state {
desc_miss = -1, /* ID mismatch */
desc_modified = 0x0, /* reserved, being modified by writer */
desc_committed = 0x1, /* committed by writer, could get reopened */
desc_finalized = 0x2, /* committed, could not longer get modified */
desc_reusable = 0x3, /* free, not yet used by any writer */
};
Second, only 4 variants of the 3 state bits are currently used.
It means that two bits are enough and they might use exactly
the above names:
I mean to do something like:
#define DESC_SV_BITS (sizeof(unsigned long) * 8)
#define DESC_SV(desc_state) ((unsigned long)desc_state << (DESC_SV_BITS - 2))
#define DESC_ST(state_val) ((unsigned long)state_val >> (DESC_SV_BITS - 2))
Then we could have:
static enum desc_state get_desc_state(unsigned long id,
unsigned long state_val)
{
if (id != DESC_ID(state_val))
return desc_miss;
return DESC_ST(state_val);
}
and use in the code:
unsigned long val_committed = id | DESC_SV(desc_committed);
or do
#define DESC_SV(id, desc_state) (id | (unsigned long)desc_state << (DESC_SV_BITS - 2))
and then use DESC_SV(id, DESC_COMMITTED).
I am sorry that I did not came up with this earlier. I know how
painful it is to rework bigger patchsets. But it affects format
of the ring buffer, so we should do it early.
Best Regards,
Petr
PS: I am still middle of review. It looks good so far. I wanted to
send this early and separately because it is a bigger change.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2020-09-02 10:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-31 1:10 [PATCH next v3 0/8] printk: reimplement LOG_CONT handling John Ogness
2020-08-31 1:10 ` [PATCH next v3 1/8] printk: ringbuffer: rename DESC_COMMITTED_MASK flag John Ogness
2020-08-31 1:10 ` [PATCH next v3 2/8] printk: ringbuffer: change representation of reusable John Ogness
2020-08-31 1:10 ` [PATCH next v3 3/8] printk: ringbuffer: relocate get_data() John Ogness
2020-08-31 1:10 ` [PATCH next v3 4/8] printk: ringbuffer: add BLK_DATALESS() macro John Ogness
2020-08-31 1:10 ` [PATCH next v3 5/8] printk: ringbuffer: clear initial reserved fields John Ogness
2020-09-01 14:33 ` Petr Mladek
2020-08-31 1:10 ` [PATCH next v3 6/8] printk: ringbuffer: add finalization/extension support John Ogness
2020-08-31 12:54 ` John Ogness
2020-09-02 10:52 ` Petr Mladek [this message]
2020-09-02 11:20 ` state names: vas: " John Ogness
2020-09-02 12:39 ` Petr Mladek
2020-09-02 10:58 ` Petr Mladek
2020-09-02 12:21 ` misc: was: " Petr Mladek
2020-08-31 1:10 ` [PATCH next v3 7/8] printk: reimplement log_cont using record extension John Ogness
2020-09-02 13:38 ` Petr Mladek
2020-08-31 1:10 ` [PATCH next v3 8/8] scripts/gdb: support printk finalized records John Ogness
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=20200902105250.GA15764@alley \
--to=pmladek@suse.com \
--cc=gregkh@linuxfoundation.org \
--cc=john.ogness@linutronix.de \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=parri.andrea@gmail.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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