On Wed, Aug 19, 2020 at 12:43:52PM -0400, Valdis Klētnieks wrote:
> On Wed, 19 Aug 2020 12:42:54 +0200, Greg KH said:
> > Look up Spectre and Meltdown for many many examples of what happened and
> > what went wrong with chip designs and how we had to fix these things in
> > the kernel a few years a
On Wed, 19 Aug 2020 12:42:54 +0200, Greg KH said:
> Look up Spectre and Meltdown for many many examples of what happened and
> what went wrong with chip designs and how we had to fix these things in
> the kernel a few years ago.
And I'm sure that nobody sane thinks we're done with security holes
c
From: Bernd Petrovitsch
> Sent: 19 August 2020 11:22
>
> On 19/08/2020 10:16, Muni Sekhar wrote:
> > On Tue, Aug 18, 2020 at 11:45 PM peter enderborg
> > wrote:
> [...]
> >> On the 4.4 kernel you dont have
> >>
> >> +CONFIG_RETPOLINE=y
> >> +CONFIG_INTEL_RDT=y
> > Thanks! That is helpful. Yes, I
On 19/08/2020 10:16, Muni Sekhar wrote:
> On Tue, Aug 18, 2020 at 11:45 PM peter enderborg
> wrote:
[...]
>> On the 4.4 kernel you dont have
>>
>> +CONFIG_RETPOLINE=y
>> +CONFIG_INTEL_RDT=y
> Thanks! That is helpful. Yes, I see 4.4 kernel don't have the above
> two config options.
> What analysis
On Wed, Aug 19, 2020 at 03:46:06PM +0530, Muni Sekhar wrote:
> On Tue, Aug 18, 2020 at 11:45 PM peter enderborg
> wrote:
> >
> > On 8/18/20 7:53 PM, Muni Sekhar wrote:
> > > On Tue, Aug 18, 2020 at 11:06 PM Greg KH wrote:
> > >> On Tue, Aug 18, 2020 at 11:01:35PM +0530, Muni Sekhar wrote:
> > >>>
On Tue, Aug 18, 2020 at 11:45 PM peter enderborg
wrote:
>
> On 8/18/20 7:53 PM, Muni Sekhar wrote:
> > On Tue, Aug 18, 2020 at 11:06 PM Greg KH wrote:
> >> On Tue, Aug 18, 2020 at 11:01:35PM +0530, Muni Sekhar wrote:
> >>> On Tue, Aug 18, 2020 at 10:44 PM Greg KH wrote:
> On Tue, Aug 18, 20
On 8/18/20 7:53 PM, Muni Sekhar wrote:
> On Tue, Aug 18, 2020 at 11:06 PM Greg KH wrote:
>> On Tue, Aug 18, 2020 at 11:01:35PM +0530, Muni Sekhar wrote:
>>> On Tue, Aug 18, 2020 at 10:44 PM Greg KH wrote:
On Tue, Aug 18, 2020 at 10:24:13PM +0530, Muni Sekhar wrote:
> On Tue, Aug 18, 2020
On Tue, Aug 18, 2020 at 11:06 PM Greg KH wrote:
>
> On Tue, Aug 18, 2020 at 11:01:35PM +0530, Muni Sekhar wrote:
> > On Tue, Aug 18, 2020 at 10:44 PM Greg KH wrote:
> > >
> > > On Tue, Aug 18, 2020 at 10:24:13PM +0530, Muni Sekhar wrote:
> > > > On Tue, Aug 18, 2020 at 8:06 PM Greg KH wrote:
> >
On Tue, Aug 18, 2020 at 11:01:35PM +0530, Muni Sekhar wrote:
> On Tue, Aug 18, 2020 at 10:44 PM Greg KH wrote:
> >
> > On Tue, Aug 18, 2020 at 10:24:13PM +0530, Muni Sekhar wrote:
> > > On Tue, Aug 18, 2020 at 8:06 PM Greg KH wrote:
> > > >
> > > > On Tue, Aug 18, 2020 at 08:00:11PM +0530, Muni S
rnel with gcc
version 7.5.0).
>
> > > > While doing kernel profiling with perf, I got the below mentioned
> > > > metrics for Scheduler benchmarks.
> > > >
> > > > 1st system (older kernel version compared to the other system)
> > > > benchma
y kernel differences.
> >
> > What are the differences in the kernels?
You didn't answer this question, is this the same kernel source being
compared here? Same version? Same compiler? Everything identical?
> > > While doing kernel profiling with perf, I got the below ment
g kernel profiling with perf, I got the below mentioned
> > metrics for Scheduler benchmarks.
> >
> > 1st system (older kernel version compared to the other system) benchmark
> > result:
> >
> > $ perf bench sched messaging -g 64
> > # Running 'sched/
g kernel profiling with perf, I got the below mentioned
> > metrics for Scheduler benchmarks.
> >
> > 1st system (older kernel version compared to the other system) benchmark
> > result:
> >
> > $ perf bench sched messaging -g 64
> > # Running 'sched/
On Tue, Aug 18, 2020 at 08:00:11PM +0530, Muni Sekhar wrote:
> Hi all,
>
> I’ve two identical Linux systems with only kernel differences.
What are the differences in the kernels?
> While doing kernel profiling with perf, I got the below mentioned
> metrics for Scheduler bench
Hi all,
I’ve two identical Linux systems with only kernel differences.
While doing kernel profiling with perf, I got the below mentioned
metrics for Scheduler benchmarks.
1st system (older kernel version compared to the other system) benchmark result:
$ perf bench sched messaging -g 64
* Rob Hussey <[EMAIL PROTECTED]> wrote:
> On 9/18/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > * Rob Hussey <[EMAIL PROTECTED]> wrote:
> >
> > > The obligatory graphs:
> > > http://www.healthcarelinen.com/misc/benchmarks/BOUND_NOPREEMPT_lat_ctx_benchmark.png
> > > http://www.healthcarelinen
On 9/18/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Rob Hussey <[EMAIL PROTECTED]> wrote:
>
> > The obligatory graphs:
> > http://www.healthcarelinen.com/misc/benchmarks/BOUND_NOPREEMPT_lat_ctx_benchmark.png
> > http://www.healthcarelinen.com/misc/benchmarks/BOUND_NOPREEMPT_hackbench_benchmark
* Rob Hussey <[EMAIL PROTECTED]> wrote:
> The obligatory graphs:
> http://www.healthcarelinen.com/misc/benchmarks/BOUND_NOPREEMPT_lat_ctx_benchmark.png
> http://www.healthcarelinen.com/misc/benchmarks/BOUND_NOPREEMPT_hackbench_benchmark.png
> http://www.healthcarelinen.com/misc/benchmarks/BOUND_N
On 9/18/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Rob Hussey <[EMAIL PROTECTED]> wrote:
>
> > A cursory glance suggests that performance wrt lat_ctx and hackbench
> > has increased (lower numbers), but degraded quite a lot for pipe-test.
> > The numbers for pipe-test are extremely stable tho
* Rob Hussey <[EMAIL PROTECTED]> wrote:
> A cursory glance suggests that performance wrt lat_ctx and hackbench
> has increased (lower numbers), but degraded quite a lot for pipe-test.
> The numbers for pipe-test are extremely stable though, while the
> numbers for hackbench are more erratic (w
On 9/18/07, Willy Tarreau <[EMAIL PROTECTED]> wrote:
> Hi Rob,
>
> On Tue, Sep 18, 2007 at 12:30:05AM -0400, Rob Hussey wrote:
> > I should have pointed out before that I don't really have a dual-core
> > system, just a P4 with Hyper-Threading (I loosely used core to refer
> > to processor).
>
> Ju
Hi Rob,
On Tue, Sep 18, 2007 at 12:30:05AM -0400, Rob Hussey wrote:
> I should have pointed out before that I don't really have a dual-core
> system, just a P4 with Hyper-Threading (I loosely used core to refer
> to processor).
Just for reference, we call them "siblings", not "cores" on HT. I bel
On 9/17/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > i've meanwhile tested hackbench 90 and the performance difference
> > between -ck and -cfs-devel seems to be mostly down to the more precise
> > (but slower) sched_clock() introduced in v2.6.23 and
On 9/17/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Rob Hussey <[EMAIL PROTECTED]> wrote:
>
> > http://www.healthcarelinen.com/misc/benchmarks/BOUND_hackbench_benchmark2.png
>
> heh - am i the only one impressed by the consistency of the blue line in
> this graph? :-) [ and the green line look
On Mon, Sep 17, 2007 at 10:06:40PM +0200, Oleg Verych wrote:
> On Mon, Sep 17, 2007 at 09:43:42PM +0200, Willy Tarreau wrote:
> >
> > On Mon, Sep 17, 2007 at 09:45:59PM +0200, Oleg Verych wrote:
> > > The copy list, removed by Ingo is restored. Playing fair game, Willy!
> >
> > Sorry Oleg, I don'
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i've meanwhile tested hackbench 90 and the performance difference
> between -ck and -cfs-devel seems to be mostly down to the more precise
> (but slower) sched_clock() introduced in v2.6.23 and to the startup
> penalty of freshly created tasks.
Rob,
* Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> Rob,
>
> I gather this was with the complete -ck patchset? It would be
> interesting to see if just SD performed as well. If it does, CFS
> needs more work. if not there are other things in -ck that really do
> improve performance and should be lo
* Willy Tarreau <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 17, 2007 at 09:45:59PM +0200, Oleg Verych wrote:
> > The copy list, removed by Ingo is restored. Playing fair game, Willy!
>
> Sorry Oleg, I don't understand why you added me to this thread. And I
> don't understand at all what your inten
* Oleg Verych <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 17, 2007 at 09:43:42PM +0200, Willy Tarreau wrote:
> >
> > On Mon, Sep 17, 2007 at 09:45:59PM +0200, Oleg Verych wrote:
> > > The copy list, removed by Ingo is restored. Playing fair game, Willy!
> >
> > Sorry Oleg, I don't understand why y
On Mon, Sep 17, 2007 at 09:43:42PM +0200, Willy Tarreau wrote:
>
> On Mon, Sep 17, 2007 at 09:45:59PM +0200, Oleg Verych wrote:
> > The copy list, removed by Ingo is restored. Playing fair game, Willy!
>
> Sorry Oleg, I don't understand why you added me to this thread. And I
> don't understand at
since they wonder like me.
Regards,
Willy
> Roman, please, find whole thread here:
> http://thread.gmane.org/gmane.linux.kernel/580665
>
> > From: Ingo Molnar <[EMAIL PROTECTED]>
> > Newsgroups: gmane.linux.kernel,gmane.linux.kernel.ck
> > Subject: Re: Scheduler
* Jos Poortvliet <[EMAIL PROTECTED]> wrote:
> On 9/17/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > * Rob Hussey <[EMAIL PROTECTED]> wrote:
> >
> > > http://www.healthcarelinen.com/misc/benchmarks/BOUND_hackbench_benchmark2.png
> >
> > heh - am i the only one impressed by the consistency of
On 9/17/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Rob Hussey <[EMAIL PROTECTED]> wrote:
>
> > http://www.healthcarelinen.com/misc/benchmarks/BOUND_hackbench_benchmark2.png
>
> heh - am i the only one impressed by the consistency of the blue line in
> this graph? :-) [ and the green line look
* Rob Hussey <[EMAIL PROTECTED]> wrote:
> http://www.healthcarelinen.com/misc/benchmarks/BOUND_hackbench_benchmark2.png
heh - am i the only one impressed by the consistency of the blue line in
this graph? :-) [ and the green line looks a bit like a .. staircase? ]
i've meanwhile tested hackben
* Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> I gather this was with the complete -ck patchset? It would be
> interesting to see if just SD performed as well. If it does, CFS
> needs more work. if not there are other things in -ck that really do
> improve performance and should be looked into.
* Rob Hussey <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> After posting some benchmarks involving cfs
> (http://lkml.org/lkml/2007/9/13/385), I got some feedback, so I
> decided to do a follow-up that'll hopefully fill in the gaps many
> people wanted to see filled.
thanks for the update!
> I'l
Rob,
I gather this was with the complete -ck patchset? It would be interesting to
see if just SD
performed as well. If it does, CFS needs more work. if not there are other
things in -ck
that really do improve performance and should be looked into.
Thanks
Ed Tomlinson
On September 17, 2007, R
Joe deBlaquiere wrote:
>
> Maybe I've been off in the hardware lab for too long, but how about
>
> 1. using ioperm to give access to the parallel port.
> 2. have your program write a byte (thread id % 256 ?) constantly to the
> port during it's other activity
> 3. capture the results from anothe
Bill Hartner wrote:
>
> Hubertus wrote :
>
> > The only problem I have with sched_yield like benchmarks is that it
> creates
> > artificial lock contention as we basically spent most of the time other
> > then context switching + syscall under the scheduler lock. This we won't
> > see in real ap
port
This way you don't run the risk of altering the scheduler behavior with
your logging procedure.
Mike Kravetz wrote:
> Last week while discussing scheduler benchmarks, Bill Hartner
> made a comment something like the following "the benchmark may
> not even be invoking the sc
On Mon, Jan 22, 2001 at 02:23:05PM -0500, Bill Hartner wrote:
> Mike K, wrote :
>
> >
> > If the above is accurate, then I am wondering what would be a
> > good scheduler benchmark for these low task count situations.
> > I could undo the optimizations in sys_sched_yield() (for testing
> > purpos
Hubertus wrote :
> The only problem I have with sched_yield like benchmarks is that it
creates
> artificial lock contention as we basically spent most of the time other
> then context switching + syscall under the scheduler lock. This we won't
> see in real apps, that's why I think the chatroom
t: [Lse-tech] more on scheduler benchmarks
Last week while discussing scheduler benchmarks, Bill Hartner
made a comment something like the following "the benchmark may
not even be invoking the scheduler as you expect". This comment
did not fully sink in until this weekend when I sta
Mike K, wrote :
>
> If the above is accurate, then I am wondering what would be a
> good scheduler benchmark for these low task count situations.
> I could undo the optimizations in sys_sched_yield() (for testing
> purposes only!), and run the existing benchmarks. Can anyone
> suggest a better s
On Monday 22 January 2001 10:30, Mike Kravetz wrote:
> Last week while discussing scheduler benchmarks, Bill Hartner
> made a comment something like the following "the benchmark may
> not even be invoking the scheduler as you expect". This comment
> did not fully sink in u
Last week while discussing scheduler benchmarks, Bill Hartner
made a comment something like the following "the benchmark may
not even be invoking the scheduler as you expect". This comment
did not fully sink in until this weekend when I started thinking
about changes made to sched_
46 matches
Mail list logo
