On 9/18/23 14:08, Matteo Rizzo wrote:
> On Fri, 15 Sept 2023 at 18:30, Lameter, Christopher
>> Problems:
>>
>> - Overhead due to more TLB lookups
>>
>> - Larger amounts of TLBs are used for the OS. Currently we are trying to
>> use the maximum mappable TLBs to reduce their numbers. This presumably
* Matteo Rizzo wrote:
> On Mon, 18 Sept 2023 at 19:39, Ingo Molnar wrote:
> >
> > What's the split of the increase in overhead due to SLAB_VIRTUAL=y, between
> > user-space execution and kernel-space execution?
> >
>
> Same benchmark as before (compiling a kernel on a system running the patch
On Tue, 19 Sept 2023 at 08:48, Matteo Rizzo wrote:
>
> On Mon, 18 Sept 2023 at 20:05, Linus Torvalds
> wrote:
> >
> > ... and equally importantly, what about DMA?
>
> I'm not exactly sure what you mean by this, I don't think this should
> affect the performance of DMA.
I was more worried about j
On September 19, 2023 9:02:07 AM PDT, Dave Hansen wrote:
>On 9/19/23 08:48, Matteo Rizzo wrote:
>>> I think the whole "make it one single compile-time option" model is
>>> completely and fundamentally broken.
>> Wouldn't making this toggleable at boot time or runtime make performance
>> even worse
On 9/19/23 08:48, Matteo Rizzo wrote:
>> I think the whole "make it one single compile-time option" model is
>> completely and fundamentally broken.
> Wouldn't making this toggleable at boot time or runtime make performance
> even worse?
Maybe.
But you can tolerate even more of a performance impa
On 9/19/23 06:42, Matteo Rizzo wrote:
> On Mon, 18 Sept 2023 at 19:39, Ingo Molnar wrote:
>> What's the split of the increase in overhead due to SLAB_VIRTUAL=y, between
>> user-space execution and kernel-space execution?
>>
> Same benchmark as before (compiling a kernel on a system running the pat
On Mon, 18 Sept 2023 at 20:05, Linus Torvalds
wrote:
>
> ... and equally importantly, what about DMA?
I'm not exactly sure what you mean by this, I don't think this should
affect the performance of DMA.
> Or what about the fixed-size slabs (aka kmalloc?) What's the point of
> "never re-use the s
On Mon, 18 Sept 2023 at 19:39, Ingo Molnar wrote:
>
> What's the split of the increase in overhead due to SLAB_VIRTUAL=y, between
> user-space execution and kernel-space execution?
>
Same benchmark as before (compiling a kernel on a system running the patched
kernel):
Intel Skylake:
LABEL
On Mon, 18 Sept 2023 at 10:39, Ingo Molnar wrote:
>
> What's the split of the increase in overhead due to SLAB_VIRTUAL=y, between
> user-space execution and kernel-space execution?
... and equally importantly, what about DMA?
Or what about the fixed-size slabs (aka kmalloc?) What's the point of
* Matteo Rizzo wrote:
> On Fri, 15 Sept 2023 at 18:30, Lameter, Christopher
> wrote:
> >
> > On Fri, 15 Sep 2023, Dave Hansen wrote:
> >
> > > What's the cost?
> >
> > The only thing that I see is 1-2% on kernel compilations (and "more on
> > machines with lots of cores")?
>
> I used kernel c
On Fri, 15 Sept 2023 at 18:30, Lameter, Christopher
wrote:
>
> On Fri, 15 Sep 2023, Dave Hansen wrote:
>
> > What's the cost?
>
> The only thing that I see is 1-2% on kernel compilations (and "more on
> machines with lots of cores")?
I used kernel compilation time (wall clock time) as a benchmark
On Fri, 15 Sep 2023, Dave Hansen wrote:
On 9/15/23 03:59, Matteo Rizzo wrote:
The goal of this patch series is to deterministically prevent cross-cache
attacks in the SLUB allocator.
What's the cost?
The only thing that I see is 1-2% on kernel compilations (and "more on
machines with lots
On 9/15/23 03:59, Matteo Rizzo wrote:
> The goal of this patch series is to deterministically prevent cross-cache
> attacks in the SLUB allocator.
What's the cost?
13 matches
Mail list logo
