All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: David Laight <David.Laight@aculab.com>
Cc: 'Andrzej Hajda' <andrzej.hajda@intel.com>,
	Arnd Bergmann <arnd@arndb.de>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	'Daniel Vetter' <daniel@ffwll.ch>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: Re: [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg
Date: Thu, 5 Jan 2023 15:57:25 +0100	[thread overview]
Message-ID: <Y7blVTSogV2miG8+@phenom.ffwll.local> (raw)
In-Reply-To: <6617dfb150f94cbb9654a585843e3287@AcuMS.aculab.com>

On Thu, Jan 05, 2023 at 02:41:43PM +0000, David Laight wrote:
> From: Daniel Vetter
> > Sent: 05 January 2023 14:13
> ...
> > > > So here we are, with Andrzej looking to add the common helper. And the
> > > > same concerns crop up. What should it be called to make it clear that
> > > > it's not atomic? Is that possible?
> > >
> > > old_value = read_write(variable, new_value);
> > >
> > > But two statements are much clearer.
> > 
> > Yeah this is my point for fetch_and_zero or any of the other proposals.
> > We're essentially replacing these two lines:
> > 
> > 	var = some->pointer->chase;
> > 	some->pointer->chase = NULL;
> > 
> > with a macro. C is verbose, and sometimes painfully so,
> 
> Try ADA or VHDL :-)
> 
> > if the pointer
> > chase is really to onerous then I think that should be refactored with a
> > meaningfully locally name variable, not fancy macros wrapped around to
> > golf a few characters away.
> 
> Provided 'var' is a local the compiler is pretty likely to only do the
> 'pointer chase' once.
> You can also do:
> 	var = NULL;
> 	swap(some->pointer->chase, var);
> and get pretty much the same object code.
> 
> > But what about swap() you ask? That one needs a temp variable, and it does
> > make sense to hide that in a ({}) block in a macro.
> 
> Sometimes, but not enough for the 'missed opportunity for swap()'
> message. 
> 
> > But for the above two
> > lines I really don't see a point outside of obfuscated C contexts.
> 
> Indeed.
> 
> Isn't the suggested __xchg() in one of the 'reserved for implementation'
> namespaces - so shouldn't be a function that might be expected to be
> actually used.

It's more fun, for the atomic functions which don't have the atomic_
prefix in their names, the __ prefixed versions provide the non-atomic
implementation.  This pattern was started with the long * bitops stuff for
managing really big bitmasks.

And I really don't think it's a great function name scheme that we should
proliferate.

The "reserved for implementation" only applies to the standard C library
in userspace, which the kernel doesn't use, so can fairly freely use that
namespace.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: David Laight <David.Laight@aculab.com>
Cc: 'Andrzej Hajda' <andrzej.hajda@intel.com>,
	Arnd Bergmann <arnd@arndb.de>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: Re: [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg
Date: Thu, 5 Jan 2023 15:57:25 +0100	[thread overview]
Message-ID: <Y7blVTSogV2miG8+@phenom.ffwll.local> (raw)
In-Reply-To: <6617dfb150f94cbb9654a585843e3287@AcuMS.aculab.com>

On Thu, Jan 05, 2023 at 02:41:43PM +0000, David Laight wrote:
> From: Daniel Vetter
> > Sent: 05 January 2023 14:13
> ...
> > > > So here we are, with Andrzej looking to add the common helper. And the
> > > > same concerns crop up. What should it be called to make it clear that
> > > > it's not atomic? Is that possible?
> > >
> > > old_value = read_write(variable, new_value);
> > >
> > > But two statements are much clearer.
> > 
> > Yeah this is my point for fetch_and_zero or any of the other proposals.
> > We're essentially replacing these two lines:
> > 
> > 	var = some->pointer->chase;
> > 	some->pointer->chase = NULL;
> > 
> > with a macro. C is verbose, and sometimes painfully so,
> 
> Try ADA or VHDL :-)
> 
> > if the pointer
> > chase is really to onerous then I think that should be refactored with a
> > meaningfully locally name variable, not fancy macros wrapped around to
> > golf a few characters away.
> 
> Provided 'var' is a local the compiler is pretty likely to only do the
> 'pointer chase' once.
> You can also do:
> 	var = NULL;
> 	swap(some->pointer->chase, var);
> and get pretty much the same object code.
> 
> > But what about swap() you ask? That one needs a temp variable, and it does
> > make sense to hide that in a ({}) block in a macro.
> 
> Sometimes, but not enough for the 'missed opportunity for swap()'
> message. 
> 
> > But for the above two
> > lines I really don't see a point outside of obfuscated C contexts.
> 
> Indeed.
> 
> Isn't the suggested __xchg() in one of the 'reserved for implementation'
> namespaces - so shouldn't be a function that might be expected to be
> actually used.

It's more fun, for the atomic functions which don't have the atomic_
prefix in their names, the __ prefixed versions provide the non-atomic
implementation.  This pattern was started with the long * bitops stuff for
managing really big bitmasks.

And I really don't think it's a great function name scheme that we should
proliferate.

The "reserved for implementation" only applies to the standard C library
in userspace, which the kernel doesn't use, so can fairly freely use that
namespace.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: David Laight <David.Laight@aculab.com>
Cc: 'Daniel Vetter' <daniel@ffwll.ch>,
	'Jani Nikula' <jani.nikula@linux.intel.com>,
	Arnd Bergmann <arnd@arndb.de>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	'Andrzej Hajda' <andrzej.hajda@intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: Re: [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg
Date: Thu, 5 Jan 2023 15:57:25 +0100	[thread overview]
Message-ID: <Y7blVTSogV2miG8+@phenom.ffwll.local> (raw)
In-Reply-To: <6617dfb150f94cbb9654a585843e3287@AcuMS.aculab.com>

On Thu, Jan 05, 2023 at 02:41:43PM +0000, David Laight wrote:
> From: Daniel Vetter
> > Sent: 05 January 2023 14:13
> ...
> > > > So here we are, with Andrzej looking to add the common helper. And the
> > > > same concerns crop up. What should it be called to make it clear that
> > > > it's not atomic? Is that possible?
> > >
> > > old_value = read_write(variable, new_value);
> > >
> > > But two statements are much clearer.
> > 
> > Yeah this is my point for fetch_and_zero or any of the other proposals.
> > We're essentially replacing these two lines:
> > 
> > 	var = some->pointer->chase;
> > 	some->pointer->chase = NULL;
> > 
> > with a macro. C is verbose, and sometimes painfully so,
> 
> Try ADA or VHDL :-)
> 
> > if the pointer
> > chase is really to onerous then I think that should be refactored with a
> > meaningfully locally name variable, not fancy macros wrapped around to
> > golf a few characters away.
> 
> Provided 'var' is a local the compiler is pretty likely to only do the
> 'pointer chase' once.
> You can also do:
> 	var = NULL;
> 	swap(some->pointer->chase, var);
> and get pretty much the same object code.
> 
> > But what about swap() you ask? That one needs a temp variable, and it does
> > make sense to hide that in a ({}) block in a macro.
> 
> Sometimes, but not enough for the 'missed opportunity for swap()'
> message. 
> 
> > But for the above two
> > lines I really don't see a point outside of obfuscated C contexts.
> 
> Indeed.
> 
> Isn't the suggested __xchg() in one of the 'reserved for implementation'
> namespaces - so shouldn't be a function that might be expected to be
> actually used.

It's more fun, for the atomic functions which don't have the atomic_
prefix in their names, the __ prefixed versions provide the non-atomic
implementation.  This pattern was started with the long * bitops stuff for
managing really big bitmasks.

And I really don't think it's a great function name scheme that we should
proliferate.

The "reserved for implementation" only applies to the standard C library
in userspace, which the kernel doesn't use, so can fairly freely use that
namespace.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2023-01-05 14:57 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-09 15:48 [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg Andrzej Hajda
2022-12-09 15:48 ` Andrzej Hajda
2022-12-09 15:48 ` Andrzej Hajda
2022-12-09 15:48 ` [Intel-gfx] [PATCH 2/5] drm/i915/display: kill fetch_and_zero usage Andrzej Hajda
2022-12-09 15:48   ` Andrzej Hajda
2022-12-09 15:48   ` Andrzej Hajda
2022-12-09 15:48 ` [Intel-gfx] [PATCH 3/5] drm/i915/gt: " Andrzej Hajda
2022-12-09 15:48   ` Andrzej Hajda
2022-12-09 15:48   ` Andrzej Hajda
2022-12-12  9:14   ` [Intel-gfx] " Upadhyay, Tejas
2022-12-12  9:14     ` Upadhyay, Tejas
2022-12-12  9:14     ` Upadhyay, Tejas
2022-12-12  9:23     ` Andrzej Hajda
2022-12-12  9:23       ` Andrzej Hajda
2022-12-09 15:48 ` [Intel-gfx] [PATCH 4/5] drm/i915/gvt: " Andrzej Hajda
2022-12-09 15:48   ` Andrzej Hajda
2022-12-09 15:48   ` Andrzej Hajda
2022-12-09 15:48 ` [Intel-gfx] [PATCH 5/5] drm/i915: kill fetch_and_zero Andrzej Hajda
2022-12-09 15:48   ` Andrzej Hajda
2022-12-09 15:48   ` Andrzej Hajda
2022-12-09 17:16 ` [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg Arnd Bergmann
2022-12-09 17:16   ` Arnd Bergmann
2022-12-09 17:16   ` Arnd Bergmann
2022-12-13  9:28   ` [Intel-gfx] " Andrzej Hajda
2022-12-13  9:28     ` Andrzej Hajda
2022-12-13  9:35     ` Arnd Bergmann
2022-12-13  9:35       ` Arnd Bergmann
2022-12-09 18:56 ` Andy Shevchenko
2022-12-09 18:56   ` Andy Shevchenko
2022-12-09 18:56   ` Andy Shevchenko
2022-12-09 18:58   ` [Intel-gfx] " Andy Shevchenko
2022-12-09 18:58     ` Andy Shevchenko
2022-12-09 18:58     ` Andy Shevchenko
2022-12-13 10:09   ` [Intel-gfx] " Andrzej Hajda
2022-12-13 10:27     ` Andy Shevchenko
2022-12-09 19:30 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/5] " Patchwork
2022-12-09 19:50 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-12-10  9:56 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-12-12  9:38 ` [Intel-gfx] [PATCH 1/5] " David Laight
2022-12-12  9:38   ` David Laight
2022-12-12  9:38   ` David Laight
2023-01-05 13:04   ` [Intel-gfx] " Daniel Vetter
2023-01-05 13:04     ` Daniel Vetter
2023-01-05 13:04     ` Daniel Vetter
2023-01-05 13:28     ` [Intel-gfx] " Jani Nikula
2023-01-05 13:34       ` David Laight
2023-01-05 13:34         ` David Laight
2023-01-05 14:13         ` Daniel Vetter
2023-01-05 14:13           ` Daniel Vetter
2023-01-05 14:13           ` Daniel Vetter
2023-01-05 14:41           ` David Laight
2023-01-05 14:41             ` David Laight
2023-01-05 14:41             ` David Laight
2023-01-05 14:57             ` Daniel Vetter [this message]
2023-01-05 14:57               ` Daniel Vetter
2023-01-05 14:57               ` Daniel Vetter
2023-01-05 16:16               ` Mark Rutland
2023-01-05 14:13         ` Tvrtko Ursulin

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=Y7blVTSogV2miG8+@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=David.Laight@aculab.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andrzej.hajda@intel.com \
    --cc=arnd@arndb.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rodrigo.vivi@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.