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 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 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 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.
&g
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 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 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 ad
On Tue, Nov 7, 2023 at 10:05 PM Stanislav Fomichev wrote:
>
> I don't understand. We require an elaborate setup to receive devmem cmsgs,
> why would some random application receive those?
A TCP socket can receive 'valid TCP packets' from many different sources,
especially with BPF hooks...
On Wed, Dec 14, 2022 at 1:34 PM Stanislaw Gruszka
wrote:
>
> On Mon, Dec 12, 2022 at 03:35:20PM +0100, Jason A. Donenfeld wrote:
> > Please CC me on future revisions.
> >
> > As of 6.2, the prandom namespace is *only* for predictable randomness.
> > There's no need to rename anything. So nack on
On Fri, Apr 21, 2023 at 1:35 PM Andrzej Hajda wrote:
>
> In case the library is tracking busy subsystem, simply
> printing stack for every active reference will spam log
> with long, hard to read, redundant stack traces. To improve
> readabilty following changes have been made:
> - reports are
>
> Signed-off-by: Andrzej Hajda
> Reviewed-by: Andi Shyti
> ---
Reviewed-by: Eric Dumazet
Thanks.
th this lock taken.
> As a bonus we can reuse this helper in ref_tracker_dir_exit.
>
> Signed-off-by: Andrzej Hajda
> Reviewed-by: Andi Shyti
> ---
SGTM, thanks.
Reviewed-by: Eric Dumazet
ed-off-by: Andrzej Hajda
> Reviewed-by: Andi Shyti
Reviewed-by: Eric Dumazet
On Tue, Apr 25, 2023 at 12:06 AM Andrzej Hajda wrote:
>
> Similar to stack_(depot|trace)_snprint the patch
> adds helper to printing stats to memory buffer.
> It will be helpful in case of debugfs.
>
> Signed-off-by: Andrzej Hajda
> Reviewed-by: Andi Shyti
Reviewed-by: Eric Dumazet
15 matches
Mail list logo
