On Wed 01-08-18 10:46:35, Dmitry Vyukov wrote:
> I guess it would be useful to have such extensive comment for each
> SLAB_TYPESAFE_BY_RCU use explaining why it is needed and how all the
> tricky aspects are handled.
>
> For example, the one in jbd2 is interesting because it memsets the
> whole
On Wed, Aug 1, 2018 at 1:40 PM, Florian Westphal wrote:
> Dmitry Vyukov wrote:
>> On Wed, Aug 1, 2018 at 12:35 PM, Florian Westphal wrote:
>> > Dmitry Vyukov wrote:
>> >> Still can't grasp all details.
>> >> There is state that we read without taking ct->ct_general.use ref
>> >> first, namely
Dmitry Vyukov wrote:
> Still can't grasp all details.
> There is state that we read without taking ct->ct_general.use ref
> first, namely ct->state and what's used by nf_ct_key_equal.
> So let's say the entry we want to find is in the list, but
> nf_conntrack_find finds a wrong entry earlier
On 08/01/2018 03:34 AM, Dmitry Vyukov wrote:
> On Wed, Aug 1, 2018 at 12:23 PM, Eric Dumazet wrote:
>> On 08/01/2018 02:03 AM, Andrey Ryabinin wrote:
>>
>>> I can't think of any advantage in not having the constructor.
>>
>> I can't see any advantage adding another indirect call,
>> in
On Tue, Jul 31, 2018 at 8:51 PM, Linus Torvalds
wrote:
> On Tue, Jul 31, 2018 at 10:49 AM Linus Torvalds
> wrote:
>>
>> So the re-use might initialize the fields lazily, not necessarily using a
>> ctor.
>
> In particular, the pattern that nf_conntrack uses looks like it is safe.
>
> If you have
On Wed, Aug 1, 2018 at 6:25 PM, Eric Dumazet wrote:
> On 08/01/2018 09:22 AM, Christopher Lameter wrote:
>> On Wed, 1 Aug 2018, Eric Dumazet wrote:
>>
>>> The idea of having a ctor() would only be a win if all the fields that
>>> can be initialized in the ctor are contiguous and fill an integral
On Wed, 1 Aug 2018, Eric Dumazet wrote:
> The idea of having a ctor() would only be a win if all the fields that
> can be initialized in the ctor are contiguous and fill an integral
> number of cache lines.
Ok. Its reducing code size and makes the object status more consistent.
Isn't that
On Wed, Aug 1, 2018 at 3:46 PM, Florian Westphal wrote:
> Dmitry Vyukov wrote:
>> If that scenario is possible that a fix would be to make
>
> Looks possible.
>
>> __nf_conntrack_find_get ever return NULL iff it got NULL from
>> nf_conntrack_find (not if any of the checks has failed).
>
> I
On Wed, Aug 1, 2018 at 1:28 PM, Eric Dumazet wrote:
> On 08/01/2018 03:34 AM, Dmitry Vyukov wrote:
>> On Wed, Aug 1, 2018 at 12:23 PM, Eric Dumazet wrote:
>>> On 08/01/2018 02:03 AM, Andrey Ryabinin wrote:
>>>
I can't think of any advantage in not having the constructor.
>>>
>>> I can't see
On Wed, Aug 1, 2018 at 12:35 PM, Florian Westphal wrote:
> Dmitry Vyukov wrote:
>> Still can't grasp all details.
>> There is state that we read without taking ct->ct_general.use ref
>> first, namely ct->state and what's used by nf_ct_key_equal.
>> So let's say the entry we want to find is in
On Wed, Aug 1, 2018 at 8:15 AM Christopher Lameter wrote:
>
> On Wed, 1 Aug 2018, Dmitry Vyukov wrote:
>
> > But we are trading 1 indirect call for comparable overhead removed
> > from much more common path. The path that does ctors is also calling
> > into page alloc, which is much more
On 08/01/2018 09:22 AM, Christopher Lameter wrote:
> On Wed, 1 Aug 2018, Eric Dumazet wrote:
>
>> The idea of having a ctor() would only be a win if all the fields that
>> can be initialized in the ctor are contiguous and fill an integral
>> number of cache lines.
>
> Ok. Its reducing code
On Wed, Aug 1, 2018 at 5:37 PM, Eric Dumazet wrote:
> On Wed, Aug 1, 2018 at 8:15 AM Christopher Lameter wrote:
>>
>> On Wed, 1 Aug 2018, Dmitry Vyukov wrote:
>>
>> > But we are trading 1 indirect call for comparable overhead removed
>> > from much more common path. The path that does ctors is
On Tue, Jul 31, 2018 at 10:10 AM Florian Westphal wrote:
>
> Andrey Ryabinin wrote:
> > Guys, it seems that we have a lot of code using SLAB_TYPESAFE_BY_RCU cache
> > without constructor.
> > I think it's nearly impossible to use that combination without having bugs.
> > It's either you don't
On Wed, Aug 1, 2018 at 10:46 AM, Dmitry Vyukov wrote:
> On Tue, Jul 31, 2018 at 8:51 PM, Linus Torvalds
> wrote:
>> On Tue, Jul 31, 2018 at 10:49 AM Linus Torvalds
>> wrote:
>>>
>>> So the re-use might initialize the fields lazily, not necessarily using a
>>> ctor.
>>
>> In particular, the
On 08/01/2018 02:03 AM, Andrey Ryabinin wrote:
> I can't think of any advantage in not having the constructor.
>
I can't see any advantage adding another indirect call,
in RETPOLINE world.
___
dri-devel mailing list
On Tue, Jul 31, 2018 at 7:41 PM, Eric Dumazet wrote:
> On Tue, Jul 31, 2018 at 10:36 AM Christopher Lameter wrote:
>
>>
>> If there is refcounting going on then why use SLAB_TYPESAFE_BY_RCU?
>
> To allow fast reuse of objects, without going through call_rcu() and
> reducing cache efficiency.
>
>
On 07/31/2018 09:51 PM, Linus Torvalds wrote:
> On Tue, Jul 31, 2018 at 10:49 AM Linus Torvalds
> wrote:
>>
>> So the re-use might initialize the fields lazily, not necessarily using a
>> ctor.
>
> In particular, the pattern that nf_conntrack uses looks like it is safe.
>
> If you have a
On Tue, Jul 31, 2018 at 10:51 AM Dmitry Vyukov wrote:
>
>
> Is it OK to overwrite ct->status? It seems that are some read and
> writes to it right after atomic_inc_not_zero.
If it is after a (successful) atomic_inc_not_zero(),
the object is guaranteed to be alive (not freed or about to be
On Wed, 1 Aug 2018, Dmitry Vyukov wrote:
> But we are trading 1 indirect call for comparable overhead removed
> from much more common path. The path that does ctors is also calling
> into page alloc, which is much more expensive.
> So ctor should be a net win on performance front, no?
ctor would
On Tue, Jul 31, 2018 at 10:36 AM Christopher Lameter wrote:
>
> If there is refcounting going on then why use SLAB_TYPESAFE_BY_RCU?
To allow fast reuse of objects, without going through call_rcu() and
reducing cache efficiency.
I believe this is mentioned in Documentation/RCU/rculist_nulls.txt
On Wed, Aug 1, 2018 at 12:23 PM, Eric Dumazet wrote:
> On 08/01/2018 02:03 AM, Andrey Ryabinin wrote:
>
>> I can't think of any advantage in not having the constructor.
>
> I can't see any advantage adding another indirect call,
> in RETPOLINE world.
Can you please elaborate what's the problem
On Tue, 31 Jul 2018, Andrey Ryabinin wrote:
> Guys, it seems that we have a lot of code using SLAB_TYPESAFE_BY_RCU cache
> without constructor.
> I think it's nearly impossible to use that combination without having bugs.
> It's either you don't really need the SLAB_TYPESAFE_BY_RCU, or you need
Dmitry Vyukov wrote:
> If that scenario is possible that a fix would be to make
Looks possible.
> __nf_conntrack_find_get ever return NULL iff it got NULL from
> nf_conntrack_find (not if any of the checks has failed).
I don't see why we need to restart on nf_ct_is_dying(), but other
than
Andrey Ryabinin wrote:
> Guys, it seems that we have a lot of code using SLAB_TYPESAFE_BY_RCU cache
> without constructor.
> I think it's nearly impossible to use that combination without having bugs.
> It's either you don't really need the SLAB_TYPESAFE_BY_RCU, or you need to
> have a
Dmitry Vyukov wrote:
> On Wed, Aug 1, 2018 at 12:35 PM, Florian Westphal wrote:
> > Dmitry Vyukov wrote:
> >> Still can't grasp all details.
> >> There is state that we read without taking ct->ct_general.use ref
> >> first, namely ct->state and what's used by nf_ct_key_equal.
> >> So let's say
On Wed, Aug 1, 2018 at 9:47 AM Dmitry Vyukov wrote:
>
> Proving with numbers is required for a claimed performance improvement
> at the cost of code degradation/increase. For a win-win change there
> is really nothing to prove.
You have to _prove_ it is a win-win.
It is not sufficient to claim
On Tue, Jul 31, 2018 at 10:49 AM Linus Torvalds
wrote:
>
> So the re-use might initialize the fields lazily, not necessarily using a
> ctor.
In particular, the pattern that nf_conntrack uses looks like it is safe.
If you have a well-defined refcount, and use "atomic_inc_not_zero()"
to guard
On Tue, Jul 31, 2018 at 10:36 AM Christopher Lameter wrote:
>
> If there is refcounting going on then why use SLAB_TYPESAFE_BY_RCU?
.. because the object can be accessed (by RCU) after the refcount has
gone down to zero, and the thing has been released.
That's the whole and only point of
29 matches
Mail list logo
