From: "Reshetova, Elena" <elena.reshetova@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: "mingo@redhat.com" <mingo@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"tj@kernel.org" <tj@kernel.org>,
"hannes@cmpxchg.org" <hannes@cmpxchg.org>,
"lizefan@huawei.com" <lizefan@huawei.com>,
"acme@kernel.org" <acme@kernel.org>,
"alexander.shishkin@linux.intel.com"
<alexander.shishkin@linux.intel.com>,
"eparis@redhat.com" <eparis@redhat.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"arnd@arndb.de" <arnd@arndb.de>,
"luto@kernel.org" <luto@kernel.org>,
"keescook@chromium.org" <keescook@chromium.org>,
"dvhart@infradead.org" <dvhart@infradead.org>,
"ebiederm@xmission.com" <ebiederm@xmission.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"axboe@kernel.dk" <axboe@kernel.dk>
Subject: RE: [PATCH 01/15] sched: convert sighand_struct.count to refcount_t
Date: Mon, 23 Oct 2017 10:45:35 +0000 [thread overview]
Message-ID: <2236FBA76BA1254E88B949DDB74E612B802B439C@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1710231223450.4241@nanos>
> On Mon, 23 Oct 2017, Reshetova, Elena wrote:
> > > On Fri, 20 Oct 2017, Elena Reshetova wrote:
> > > How did you make sure that these atomic operations have no other
> > > serialization effect and can be replaced with refcount?
> >
> > What serialization effects? Are you taking about smth else than memory
> > ordering?
>
> Well, the memory ordering constraints can be part of serialization
> mechanisms. Unfortunately they are not well documented ....
Would you be able to point to any documentation or examples of this?
I would be happy to understand more, it is really not smth very straightforward.
The reason I also don't want to confuse people even more with this ordering issue
is that it can be different if you use arch. specific implementation vs. arch. independent.
So, it is not as simple as to say "refcount_t would always result in weak memory ordering",
it really depends what REFCOUNT config option is "on", what arch. you are running on etc.
Nothing to add is that by default refount_t = atomic_t unless you start enabling
the related configs...
>
> > For memory ordering my current hope is that we can just make refcount_t
> > to use same strict atomic primitives and then it would not make any
> > difference. I think this would be the simplest way for everyone since I
> > think even some maintainers are having issues understanding all the
> > implications of "relaxed" ordering.
>
> Well, that would make indeed the conversion simpler because then it is just
> a drop in replacement. Albeit there might be some places which benefit of
> the relaxed ordering as on some architectures strict ordering is expensive.
Well refcount_t was not meant to provide any other benefits from atomic_t apart from
better security guarantees and potentially better written code (less possibilities to do smth
stupid with a smaller API). If someone really have an issue with speed, they should be enabling
arch. specific refcount_t implementation for their arch. anyway and then it is hopefully does
it the best possible/faster way.
Best Regards,
Elena.
>
> Thanks,
>
> tglx
WARNING: multiple messages have this Message-ID (diff)
From: "Reshetova, Elena" <elena.reshetova@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: "mingo@redhat.com" <mingo@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"tj@kernel.org" <tj@kernel.org>,
"hannes@cmpxchg.org" <hannes@cmpxchg.org>,
"lizefan@huawei.com" <lizefan@huawei.com>,
"acme@kernel.org" <acme@kernel.org>,
"alexander.shishkin@linux.intel.com"
<alexander.shishkin@linux.intel.com>,
"eparis@redhat.com" <eparis@redhat.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"arnd@arndb.de" <arnd@arndb.de>,
"luto@kernel.org" <luto@kernel.org>,
"keescook@chromium.org" <keescook@chromium.org>,
"dvhart@infradead.org" <dvhart@infradead.org>,
"ebiederm@xmission.com" <ebiederm@xmission.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"axboe@kernel.dk" <axboe@kernel.dk>
Subject: RE: [PATCH 01/15] sched: convert sighand_struct.count to refcount_t
Date: Mon, 23 Oct 2017 10:45:35 +0000 [thread overview]
Message-ID: <2236FBA76BA1254E88B949DDB74E612B802B439C@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1710231223450.4241@nanos>
> On Mon, 23 Oct 2017, Reshetova, Elena wrote:
> > > On Fri, 20 Oct 2017, Elena Reshetova wrote:
> > > How did you make sure that these atomic operations have no other
> > > serialization effect and can be replaced with refcount?
> >
> > What serialization effects? Are you taking about smth else than memory
> > ordering?
>
> Well, the memory ordering constraints can be part of serialization
> mechanisms. Unfortunately they are not well documented ....
Would you be able to point to any documentation or examples of this?
I would be happy to understand more, it is really not smth very straightforward.
The reason I also don't want to confuse people even more with this ordering issue
is that it can be different if you use arch. specific implementation vs. arch. independent.
So, it is not as simple as to say "refcount_t would always result in weak memory ordering",
it really depends what REFCOUNT config option is "on", what arch. you are running on etc.
Nothing to add is that by default refount_t = atomic_t unless you start enabling
the related configs...
>
> > For memory ordering my current hope is that we can just make refcount_t
> > to use same strict atomic primitives and then it would not make any
> > difference. I think this would be the simplest way for everyone since I
> > think even some maintainers are having issues understanding all the
> > implications of "relaxed" ordering.
>
> Well, that would make indeed the conversion simpler because then it is just
> a drop in replacement. Albeit there might be some places which benefit of
> the relaxed ordering as on some architectures strict ordering is expensive.
Well refcount_t was not meant to provide any other benefits from atomic_t apart from
better security guarantees and potentially better written code (less possibilities to do smth
stupid with a smaller API). If someone really have an issue with speed, they should be enabling
arch. specific refcount_t implementation for their arch. anyway and then it is hopefully does
it the best possible/faster way.
Best Regards,
Elena.
>
> Thanks,
>
> tglx
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-10-23 10:45 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-20 12:15 [PATCH 00/15] v5 kernel core pieces refcount conversions Elena Reshetova
2017-10-20 12:15 ` Elena Reshetova
2017-10-20 12:15 ` [PATCH 01/15] sched: convert sighand_struct.count to refcount_t Elena Reshetova
2017-10-20 12:15 ` Elena Reshetova
2017-10-20 12:43 ` Thomas Gleixner
2017-10-20 12:43 ` Thomas Gleixner
2017-10-23 10:22 ` Reshetova, Elena
2017-10-23 10:22 ` Reshetova, Elena
2017-10-23 10:26 ` Thomas Gleixner
2017-10-23 10:26 ` Thomas Gleixner
2017-10-23 10:26 ` Thomas Gleixner
2017-10-23 10:45 ` Reshetova, Elena [this message]
2017-10-23 10:45 ` Reshetova, Elena
2017-10-20 12:15 ` [PATCH 02/15] sched: convert signal_struct.sigcnt " Elena Reshetova
2017-10-20 12:15 ` Elena Reshetova
2017-10-20 12:15 ` [PATCH 03/15] sched: convert user_struct.__count " Elena Reshetova
2017-10-20 12:15 ` Elena Reshetova
2017-10-20 12:15 ` [PATCH 04/15] sched: convert numa_group.refcount " Elena Reshetova
2017-10-20 12:15 ` Elena Reshetova
2017-10-20 12:15 ` [PATCH 05/15] sched/task_struct: convert task_struct.usage " Elena Reshetova
2017-10-20 12:15 ` Elena Reshetova
2017-10-20 12:15 ` [PATCH 06/15] sched/task_struct: convert task_struct.stack_refcount " Elena Reshetova
2017-10-20 12:15 ` Elena Reshetova
2017-10-20 12:15 ` [PATCH 07/15] perf: convert perf_event_context.refcount " Elena Reshetova
2017-10-20 12:15 ` Elena Reshetova
2017-10-20 12:15 ` [PATCH 08/15] perf/ring_buffer: convert ring_buffer.refcount " Elena Reshetova
2017-10-20 12:15 ` Elena Reshetova
2017-10-20 12:15 ` [PATCH 09/15] perf/ring_buffer: convert ring_buffer.aux_refcount " Elena Reshetova
2017-10-20 12:15 ` Elena Reshetova
2017-10-20 12:15 ` [PATCH 10/15] uprobes: convert uprobe.ref " Elena Reshetova
2017-10-20 12:15 ` Elena Reshetova
2017-10-20 12:15 ` [PATCH 11/15] nsproxy: convert nsproxy.count " Elena Reshetova
2017-10-20 12:15 ` Elena Reshetova
2017-10-20 12:15 ` [PATCH 12/15] groups: convert group_info.usage " Elena Reshetova
2017-10-20 12:15 ` Elena Reshetova
2017-10-20 12:15 ` [PATCH 13/15] creds: convert cred.usage " Elena Reshetova
2017-10-20 12:15 ` Elena Reshetova
2017-10-20 12:15 ` [PATCH 14/15] kcov: convert kcov.refcount " Elena Reshetova
2017-10-20 12:15 ` Elena Reshetova
2017-10-20 12:15 ` [PATCH 15/15] bdi: convert bdi_writeback_congested.refcnt from atomic_t " Elena Reshetova
2017-10-20 12:15 ` Elena Reshetova
-- strict thread matches above, loose matches on Subject: below --
2017-08-30 12:22 [PATCH 00/15] v5 kernel core pieces refcount conversions Elena Reshetova
2017-08-30 12:22 ` [PATCH 01/15] sched: convert sighand_struct.count to refcount_t Elena Reshetova
2017-08-25 9:41 [PATCH 00/15] v4 kernel core pieces refcount conversions Elena Reshetova
2017-08-25 9:41 ` [PATCH 01/15] sched: convert sighand_struct.count to refcount_t Elena Reshetova
2017-07-18 10:29 [PATCH 00/15] v4 kernel core pieces refcount conversions Elena Reshetova
2017-07-18 10:29 ` [PATCH 01/15] sched: convert sighand_struct.count to refcount_t Elena Reshetova
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=2236FBA76BA1254E88B949DDB74E612B802B439C@IRSMSX102.ger.corp.intel.com \
--to=elena.reshetova@intel.com \
--cc=acme@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=arnd@arndb.de \
--cc=axboe@kernel.dk \
--cc=dvhart@infradead.org \
--cc=ebiederm@xmission.com \
--cc=eparis@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizefan@huawei.com \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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.