From: John Ogness <john.ogness@linutronix.de> To: Petr Mladek <pmladek@suse.com> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>, Sergey Senozhatsky <sergey.senozhatsky@gmail.com>, Steven Rostedt <rostedt@goodmis.org>, Linus Torvalds <torvalds@linux-foundation.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Thomas Gleixner <tglx@linutronix.de>, Peter Zijlstra <peterz@infradead.org>, Andrea Parri <parri.andrea@gmail.com>, Paul McKenney <paulmck@kernel.org>, kexec@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: state names: vas: Re: [PATCH next v3 6/8] printk: ringbuffer: add finalization/extension support Date: Wed, 02 Sep 2020 13:26:14 +0206 [thread overview] Message-ID: <87r1rkctn5.fsf@jogness.linutronix.de> (raw) In-Reply-To: <20200902105250.GA15764@alley> On 2020-09-02, Petr Mladek <pmladek@suse.com> wrote: >> +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 Agreed. > I has been actually getting less and less happy with the inconsistency > between names of the bits and states. > > ... > > First, define 5 desc_states, something like: > > enum desc_state { > desc_miss = -1, /* ID mismatch */ > desc_modified = 0x0, /* reserved, being modified by writer */ I prefer the "desc_reserved" name. It may or may not have be modified yet. > 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)) This makes sense and will get us back the bit we lost because of finalization. > 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. Agreed. I am wondering if VMCOREINFO should include a DESC_FLAGS_MASK so that crash tools could at least successfully iterate the ID's, even if they didn't know what all the flag values mean (in the case that more bits are added later). > 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. Thanks for the heads up. John Ogness
WARNING: multiple messages have this Message-ID (diff)
From: John Ogness <john.ogness@linutronix.de> To: Petr Mladek <pmladek@suse.com> 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: Re: state names: vas: Re: [PATCH next v3 6/8] printk: ringbuffer: add finalization/extension support Date: Wed, 02 Sep 2020 13:26:14 +0206 [thread overview] Message-ID: <87r1rkctn5.fsf@jogness.linutronix.de> (raw) In-Reply-To: <20200902105250.GA15764@alley> On 2020-09-02, Petr Mladek <pmladek@suse.com> wrote: >> +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 Agreed. > I has been actually getting less and less happy with the inconsistency > between names of the bits and states. > > ... > > First, define 5 desc_states, something like: > > enum desc_state { > desc_miss = -1, /* ID mismatch */ > desc_modified = 0x0, /* reserved, being modified by writer */ I prefer the "desc_reserved" name. It may or may not have be modified yet. > 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)) This makes sense and will get us back the bit we lost because of finalization. > 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. Agreed. I am wondering if VMCOREINFO should include a DESC_FLAGS_MASK so that crash tools could at least successfully iterate the ID's, even if they didn't know what all the flag values mean (in the case that more bits are added later). > 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. Thanks for the heads up. John Ogness _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2020-09-02 11:20 UTC|newest] Thread overview: 34+ 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 ` 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 ` 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 ` John Ogness 2020-08-31 1:10 ` [PATCH next v3 3/8] printk: ringbuffer: relocate get_data() John Ogness 2020-08-31 1:10 ` 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 ` John Ogness 2020-08-31 1:10 ` [PATCH next v3 5/8] printk: ringbuffer: clear initial reserved fields John Ogness 2020-08-31 1:10 ` John Ogness 2020-09-01 14:33 ` Petr Mladek 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 1:10 ` John Ogness 2020-08-31 12:54 ` John Ogness 2020-08-31 12:54 ` John Ogness 2020-09-02 10:52 ` state names: vas: " Petr Mladek 2020-09-02 10:52 ` Petr Mladek 2020-09-02 11:20 ` John Ogness [this message] 2020-09-02 11:20 ` John Ogness 2020-09-02 12:39 ` Petr Mladek 2020-09-02 12:39 ` Petr Mladek 2020-09-02 10:58 ` Petr Mladek 2020-09-02 10:58 ` Petr Mladek 2020-09-02 12:21 ` misc: was: " Petr Mladek 2020-09-02 12:21 ` Petr Mladek 2020-08-31 1:10 ` [PATCH next v3 7/8] printk: reimplement log_cont using record extension John Ogness 2020-08-31 1:10 ` John Ogness 2020-09-02 13:38 ` Petr Mladek 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 2020-08-31 1:10 ` 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=87r1rkctn5.fsf@jogness.linutronix.de \ --to=john.ogness@linutronix.de \ --cc=gregkh@linuxfoundation.org \ --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=pmladek@suse.com \ --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: linkBe 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.