Hi Maciej,
Thanks for the detailed answer! Unfortunately, I don't think that I could
accomplish this task in my spare time:(
Please, don't take this as an offence but as a fix for my case I thought of an
utter hack:
I do know that writing a file by calling fallocate can be tricked and
redirec
There are cases in the kernel where we read/write global memory locklessly,
and accept the races either because it is part of the design (eg low-level
scheduling) or we simply don't care (eg global stats).
In these cases, we want to access the memory only once, and need to ensure
the compiler doe
On Wed, Nov 06, 2019 at 12:31:37PM +0100, Maxime Villard wrote:
> __read_once(x)
> __write_once(x, val)
The names are really not helpfull for understanding what is supposed to happen
here.
Martin
Le 06/11/2019 à 12:38, Martin Husemann a écrit :
On Wed, Nov 06, 2019 at 12:31:37PM +0100, Maxime Villard wrote:
__read_once(x)
__write_once(x, val)
The names are really not helpfull for understanding what is supposed to happen
here.
I don't know if you have a better suggesti
On 06.11.2019 12:51, Maxime Villard wrote:
> Le 06/11/2019 à 12:38, Martin Husemann a écrit :
>> On Wed, Nov 06, 2019 at 12:31:37PM +0100, Maxime Villard wrote:
>>> __read_once(x)
>>> __write_once(x, val)
>>
>> The names are really not helpfull for understanding what is supposed
>> to happe
On 06.11.2019 14:37, Jason Thorpe wrote:
>
>
>> On Nov 6, 2019, at 4:45 AM, Kamil Rytarowski wrote:
>>
>> I propose __write_relaxed() / __read_relaxed().
>
> ...except that seems to imply the opposite of what these do.
>
> -- thorpej
>
Rationale?
This matches atomic_load_relaxed() / atomic_
> On Nov 6, 2019, at 4:45 AM, Kamil Rytarowski wrote:
>
> I propose __write_relaxed() / __read_relaxed().
...except that seems to imply the opposite of what these do.
-- thorpej
> On Nov 6, 2019, at 5:41 AM, Kamil Rytarowski wrote:
>
> On 06.11.2019 14:37, Jason Thorpe wrote:
>>
>>
>>> On Nov 6, 2019, at 4:45 AM, Kamil Rytarowski wrote:
>>>
>>> I propose __write_relaxed() / __read_relaxed().
>>
>> ...except that seems to imply the opposite of what these do.
>>
>
On Wed, Nov 06, 2019 at 06:57:07AM -0800, Jason Thorpe wrote:
> > This matches atomic_load_relaxed() / atomic_write_relaxed(), but we do
> > not deal with atomics here.
>
> Fair enough. To me, the names suggest "compiler is allowed to apply
> relaxed constraints and tear the access if it wants"..
On 06.11.2019 15:57, Jason Thorpe wrote:
>
>
>> On Nov 6, 2019, at 5:41 AM, Kamil Rytarowski wrote:
>>
>> On 06.11.2019 14:37, Jason Thorpe wrote:
>>>
>>>
On Nov 6, 2019, at 4:45 AM, Kamil Rytarowski wrote:
I propose __write_relaxed() / __read_relaxed().
>>>
>>> ...except that se
On 06.11.2019 16:44, Kamil Rytarowski wrote:
> On 06.11.2019 15:57, Jason Thorpe wrote:
>>
>>
>>> On Nov 6, 2019, at 5:41 AM, Kamil Rytarowski wrote:
>>>
>>> On 06.11.2019 14:37, Jason Thorpe wrote:
> On Nov 6, 2019, at 4:45 AM, Kamil Rytarowski wrote:
>
> I propose __write_
On Wed, Nov 06, 2019 at 06:57:07AM -0800, Jason Thorpe wrote:
>
>
> > On Nov 6, 2019, at 5:41 AM, Kamil Rytarowski wrote:
> >
> > On 06.11.2019 14:37, Jason Thorpe wrote:
> >>
> >>
> >>> On Nov 6, 2019, at 4:45 AM, Kamil Rytarowski wrote:
> >>>
> >>> I propose __write_relaxed() / __read_rel
On Wed, 6 Nov 2019 at 09:57, Jason Thorpe wrote:
>
>
>
> > On Nov 6, 2019, at 5:41 AM, Kamil Rytarowski wrote:
> >
> > On 06.11.2019 14:37, Jason Thorpe wrote:
> >>
> >>
> >>> On Nov 6, 2019, at 4:45 AM, Kamil Rytarowski wrote:
> >>>
> >>> I propose __write_relaxed() / __read_relaxed().
> >>
> >
On 06.11.2019 16:58, David Young wrote:
> I *think* the intention is for __read_once()/__write_once() to
> load/store the entire variable from/to memory precisely once. They
> provide no guarantees about atomicity of the load/store. Should
> something be said about ordering and visibility of stor
On Wed, 6 Nov 2019 at 16:51, Kamil Rytarowski wrote:
>
> On 06.11.2019 16:44, Kamil Rytarowski wrote:
> > On 06.11.2019 15:57, Jason Thorpe wrote:
> >>
> >>
> >>> On Nov 6, 2019, at 5:41 AM, Kamil Rytarowski wrote:
> >>>
> >>> On 06.11.2019 14:37, Jason Thorpe wrote:
>
>
> > On Nov
Le 06/11/2019 à 17:37, Marco Elver a écrit :
On Wed, 6 Nov 2019 at 16:51, Kamil Rytarowski wrote:
On 06.11.2019 16:44, Kamil Rytarowski wrote:
On 06.11.2019 15:57, Jason Thorpe wrote:
On Nov 6, 2019, at 5:41 AM, Kamil Rytarowski wrote:
On 06.11.2019 14:37, Jason Thorpe wrote:
On Nov
> - Is 'volatile' a guarantee that the compiler will emit only one
> instruction to fetch the value?
No. For some types, some compilers, and some architectures, it may be,
but it is implementation-dependent. (For some types, on some
architectures, it cannot be; for example, consider a 64-b
On Wed, 6 Nov 2019 at 18:08, Maxime Villard wrote:
>
> Le 06/11/2019 à 17:37, Marco Elver a écrit :
> > On Wed, 6 Nov 2019 at 16:51, Kamil Rytarowski wrote:
> >>
> >> On 06.11.2019 16:44, Kamil Rytarowski wrote:
> >>> On 06.11.2019 15:57, Jason Thorpe wrote:
>
>
> > On Nov 6, 2019,
Hi,
There have been some discussions amongst the developers about the C11
memory model. It seemed that there was a lot of confusion and a general
lack of clarity in this subject. I wrote a quick summary describing some
of the key points of the C11 memory model and key aspects of the memory
fence
Maxime Villard wrote:
> There are cases in the kernel where we read/write global memory
> locklessly, and accept the races either because it is part of the design
> (eg low-level scheduling) or we simply don't care (eg global stats).
>
> In these cases, we want to access the memory only once, and
Le 06/11/2019 à 20:38, Mindaugas Rasiukevicius a écrit :
Maxime Villard wrote:
There are cases in the kernel where we read/write global memory
locklessly, and accept the races either because it is part of the design
(eg low-level scheduling) or we simply don't care (eg global stats).
In these
> - If we do not want to stick with the C11 API (its emulation), then I
> would suggest to use the similar terminology, e.g. atomic_load_relaxed()
> and atomic_store_relaxed(), or Linux READ_ONCE()/WRITE_ONCE(). There is
> no reason invent new terminology; it might just add more confusion.
i real
On 06.11.2019 20:38, Mindaugas Rasiukevicius wrote:
> Maxime Villard wrote:
>> There are cases in the kernel where we read/write global memory
>> locklessly, and accept the races either because it is part of the design
>> (eg low-level scheduling) or we simply don't care (eg global stats).
>>
>> I
Maxime Villard wrote:
> > - If we do not want to stick with the C11 API (its emulation), then I
> > would suggest to use the similar terminology, e.g. atomic_load_relaxed()
> > and atomic_store_relaxed(), or Linux READ_ONCE()/WRITE_ONCE(). There is
> > no reason invent new terminology; it might j
24 matches
Mail list logo
