The problem, IMHO, is none of this is in any way:
* documented;
* modellable by a user;
* explorable by a user (eg by an easy version of schedgraph to explore
things in a useful way.
Arnaud raises a valid point - he's given a synthetic benchmark whose
numbers are unpredictable. He's asking why. T
On Tue, 10 Apr 2012 16:50:39 -0400
Arnaud Lacombe wrote:
> On Tue, Apr 10, 2012 at 4:05 PM, Mike Meyer wrote:
> > On Tue, 10 Apr 2012 12:58:00 -0400
> > Arnaud Lacombe wrote:
> >> Let me disagree on your conclusion. If OS A does a task in X seconds,
> >> and OS B does the same task in Y seconds,
Hi,
On Tue, Apr 10, 2012 at 4:05 PM, Mike Meyer wrote:
> On Tue, 10 Apr 2012 12:58:00 -0400
> Arnaud Lacombe wrote:
>> Let me disagree on your conclusion. If OS A does a task in X seconds,
>> and OS B does the same task in Y seconds, if Y > X, then OS B is just
>> not performing good enough.
>
>
On Tue, 10 Apr 2012 12:58:00 -0400
Arnaud Lacombe wrote:
> Let me disagree on your conclusion. If OS A does a task in X seconds,
> and OS B does the same task in Y seconds, if Y > X, then OS B is just
> not performing good enough.
Others have pointed out one problem with this statement. Let me po
On 04/10/12 21:46, Arnaud Lacombe wrote:
On Tue, Apr 10, 2012 at 1:53 PM, Alexander Motin wrote:
On 04/10/12 20:18, Alexander Motin wrote:
On 04/10/12 19:58, Arnaud Lacombe wrote:
2012/4/9 Alexander Motin:
I have strong feeling that while this test may be interesting for
profiling,
it's own
Hi,
On Tue, Apr 10, 2012 at 1:53 PM, Alexander Motin wrote:
> On 04/10/12 20:18, Alexander Motin wrote:
>>
>> On 04/10/12 19:58, Arnaud Lacombe wrote:
>>>
>>> 2012/4/9 Alexander Motin:
[...]
I have strong feeling that while this test may be interesting for
profiling,
On 04/10/12 20:18, Alexander Motin wrote:
On 04/10/12 19:58, Arnaud Lacombe wrote:
2012/4/9 Alexander Motin:
[...]
I have strong feeling that while this test may be interesting for
profiling,
it's own results in first place depend not from how fast scheduler
is, but
from the pipes capacity and
On 04/10/12 19:58, Arnaud Lacombe wrote:
2012/4/9 Alexander Motin:
[...]
I have strong feeling that while this test may be interesting for profiling,
it's own results in first place depend not from how fast scheduler is, but
from the pipes capacity and other alike things. Can somebody hint me w
Hi,
2012/4/9 Alexander Motin :
> [...]
>
> I have strong feeling that while this test may be interesting for profiling,
> it's own results in first place depend not from how fast scheduler is, but
> from the pipes capacity and other alike things. Can somebody hint me what
> except pipe capacity an
On 04/05/12 21:45, Alexander Motin wrote:
On 05.04.2012 21:12, Arnaud Lacombe wrote:
Hi,
[Sorry for the delay, I got a bit sidetrack'ed...]
2012/2/17 Alexander Motin:
On 17.02.2012 18:53, Arnaud Lacombe wrote:
On Fri, Feb 17, 2012 at 11:29 AM, Alexander Motin
wrote:
On 02/15/12 21:54, Jef
On 04/06/12 17:30, Attilio Rao wrote:
Il 06 aprile 2012 15:27, Alexander Motin ha scritto:
On 04/06/12 17:13, Attilio Rao wrote:
Il 05 aprile 2012 19:12, Arnaud Lacombeha scritto:
Hi,
[Sorry for the delay, I got a bit sidetrack'ed...]
2012/2/17 Alexander Motin:
On 17.02.2012 18:53,
Il 06 aprile 2012 15:27, Alexander Motin ha scritto:
> On 04/06/12 17:13, Attilio Rao wrote:
>>
>> Il 05 aprile 2012 19:12, Arnaud Lacombe ha scritto:
>>>
>>> Hi,
>>>
>>> [Sorry for the delay, I got a bit sidetrack'ed...]
>>>
>>> 2012/2/17 Alexander Motin:
On 17.02.2012 18:53, Arnaud La
On 04/06/12 17:13, Attilio Rao wrote:
Il 05 aprile 2012 19:12, Arnaud Lacombe ha scritto:
Hi,
[Sorry for the delay, I got a bit sidetrack'ed...]
2012/2/17 Alexander Motin:
On 17.02.2012 18:53, Arnaud Lacombe wrote:
On Fri, Feb 17, 2012 at 11:29 AM, Alexander Motinwrote:
On 02/15/12 2
Il 05 aprile 2012 19:12, Arnaud Lacombe ha scritto:
> Hi,
>
> [Sorry for the delay, I got a bit sidetrack'ed...]
>
> 2012/2/17 Alexander Motin :
>> On 17.02.2012 18:53, Arnaud Lacombe wrote:
>>>
>>> On Fri, Feb 17, 2012 at 11:29 AM, Alexander Motin wrote:
On 02/15/12 21:54, Jeff Roberso
On 05.04.2012 21:12, Arnaud Lacombe wrote:
Hi,
[Sorry for the delay, I got a bit sidetrack'ed...]
2012/2/17 Alexander Motin:
On 17.02.2012 18:53, Arnaud Lacombe wrote:
On Fri, Feb 17, 2012 at 11:29 AM, Alexander Motinwrote:
On 02/15/12 21:54, Jeff Roberson wrote:
On Wed, 15 Feb 2012,
Hi,
[Sorry for the delay, I got a bit sidetrack'ed...]
2012/2/17 Alexander Motin :
> On 17.02.2012 18:53, Arnaud Lacombe wrote:
>>
>> On Fri, Feb 17, 2012 at 11:29 AM, Alexander Motin wrote:
>>>
>>> On 02/15/12 21:54, Jeff Roberson wrote:
On Wed, 15 Feb 2012, Alexander Motin wrote:
>>>
В Sat, 03 Mar 2012 18:30:50 +0200
Alexander Motin пишет:
> On 03.03.2012 17:26, Ivan Klymenko wrote:
> > I have FreeBSD 10.0-CURRENT #0 r232253M
> > Patch in r232454 broken my DRM
> > My system patched http://people.freebsd.org/~kib/drm/all.13.5.patch
> > After build kernel with only r232454 patc
On 03.03.2012 18:57, Mario Lobo wrote:
On Saturday 03 March 2012 13:30:50 Alexander Motin wrote:
On 03.03.2012 17:26, Ivan Klymenko wrote:
I have FreeBSD 10.0-CURRENT #0 r232253M
Patch in r232454 broken my DRM
My system patched http://people.freebsd.org/~kib/drm/all.13.5.patch
After build kerne
On Saturday 03 March 2012 13:30:50 Alexander Motin wrote:
> On 03.03.2012 17:26, Ivan Klymenko wrote:
> > I have FreeBSD 10.0-CURRENT #0 r232253M
> > Patch in r232454 broken my DRM
> > My system patched http://people.freebsd.org/~kib/drm/all.13.5.patch
> > After build kernel with only r232454 patch
On 03.03.2012 17:26, Ivan Klymenko wrote:
I have FreeBSD 10.0-CURRENT #0 r232253M
Patch in r232454 broken my DRM
My system patched http://people.freebsd.org/~kib/drm/all.13.5.patch
After build kernel with only r232454 patch Xorg log contains:
...
[ 504.865] [drm] failed to load kernel module "i
В Sat, 03 Mar 2012 14:54:17 +0200
Alexander Motin пишет:
> On 03/03/12 11:12, Alexander Motin wrote:
> > On 03/03/12 10:59, Adrian Chadd wrote:
> >> Right. Is this written up in a PR somewhere explaining the problem
> >> in as much depth has you just have?
> >
> > Have no idea. I am new at this a
On 03/03/12 11:12, Alexander Motin wrote:
On 03/03/12 10:59, Adrian Chadd wrote:
Right. Is this written up in a PR somewhere explaining the problem in
as much depth has you just have?
Have no idea. I am new at this area and haven't looked on PRs yet.
And thanks for this, it's great to see so
On 03/03/12 10:59, Adrian Chadd wrote:
Right. Is this written up in a PR somewhere explaining the problem in
as much depth has you just have?
Have no idea. I am new at this area and haven't looked on PRs yet.
And thanks for this, it's great to see some further explanation of the
current issue
Right. Is this written up in a PR somewhere explaining the problem in
as much depth has you just have?
And thanks for this, it's great to see some further explanation of the
current issues the scheduler faces.
Adrian
On 2 March 2012 23:40, Alexander Motin wrote:
> Hi.
>
>
> On 03/03/12 05:24,
В Fri, 2 Mar 2012 19:24:42 -0800
Adrian Chadd пишет:
> He's reporting that your ULE work hasn't improved his (very)
> degenerate case.
That's not true!
Thanks!
>
> Thanks!
>
>
> Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.free
Hi.
On 03/03/12 05:24, Adrian Chadd wrote:
mav@, can you please take a look at George's traces and see if there's
anything obviously silly going on?
He's reporting that your ULE work hasn't improved his (very) degenerate case.
As I can see, my patch has nothing to do with the problem. My patch
Hi,
CC'ing mav@, who started this thread.
mav@, can you please take a look at George's traces and see if there's
anything obviously silly going on?
He's reporting that your ULE work hasn't improved his (very) degenerate case.
Thanks!
Adrian
On 2 March 2012 16:14, George Mitchell wrote:
> On
On 03/02/12 18:06, Adrian Chadd wrote:
Hi George,
Have you thought about providing schedgraph traces with your
particular workload?
I'm sure that'll help out the scheduler hackers quite a bit.
THanks,
Adrian
I posted a couple back in December but I haven't created any more
recently:
http
Hi George,
Have you thought about providing schedgraph traces with your
particular workload?
I'm sure that'll help out the scheduler hackers quite a bit.
THanks,
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis
On 02/27/12 06:28, Olivier Smedts wrote:
2012/2/27 George Mitchell:
On 02/27/12 05:35, Olivier Smedts wrote:
2012/2/27 George Mitchell:
I finally got around to trying this on a 9.0-STABLE GENERIC kernel, in
the forlorn hope that it would fix SCHED_ULE's poor performance for
interactive proce
on 27/02/2012 13:28 Olivier Smedts said the following:
> Can you try with hald, or directly with the mouse device, without
> using moused ? Others reported they had better interactivity without
> sysmouse/moused. Really better (no mouse lag or freeze when under high
> load).
>
I wonder if re-nice
2012/2/27 George Mitchell :
> On 02/27/12 05:35, Olivier Smedts wrote:
>>
>> 2012/2/27 George Mitchell:
>>>
>>> I finally got around to trying this on a 9.0-STABLE GENERIC kernel, in
>>> the forlorn hope that it would fix SCHED_ULE's poor performance for
>>> interactive processes with a full load o
On 02/27/12 05:35, Olivier Smedts wrote:
2012/2/27 George Mitchell:
I finally got around to trying this on a 9.0-STABLE GENERIC kernel, in
the forlorn hope that it would fix SCHED_ULE's poor performance for
interactive processes with a full load on interactive processes. It
doesn't help.
2012/2/27 George Mitchell :
> I finally got around to trying this on a 9.0-STABLE GENERIC kernel, in
> the forlorn hope that it would fix SCHED_ULE's poor performance for
> interactive processes with a full load on interactive processes. It
> doesn't help. --
On 02/26/12 19:32, George Mitchell wrote:
> [...] SCHED_ULE's poor performance for
> interactive processes with a full load on interactive processes. It
^^
Should be "of compute-bound".
> doesn't help. -- George Mitchell
>
__
On 02/17/12 12:03, Alexander Motin wrote:
On 17.02.2012 18:53, Arnaud Lacombe wrote:
On Fri, Feb 17, 2012 at 11:29 AM, Alexander Motin wrote:
[...]So I believe this code works as it should.
Here is the patch: http://people.freebsd.org/~mav/sched.htt40.patch
I plan this to be a final patch of
On 17.02.2012 18:53, Arnaud Lacombe wrote:
On Fri, Feb 17, 2012 at 11:29 AM, Alexander Motin wrote:
On 02/15/12 21:54, Jeff Roberson wrote:
On Wed, 15 Feb 2012, Alexander Motin wrote:
I've decided to stop those cache black magic practices and focus on
things that really exist in this world --
Hi,
On Fri, Feb 17, 2012 at 11:29 AM, Alexander Motin wrote:
> On 02/15/12 21:54, Jeff Roberson wrote:
>>
>> On Wed, 15 Feb 2012, Alexander Motin wrote:
>>>
>>> I've decided to stop those cache black magic practices and focus on
>>> things that really exist in this world -- SMT and CPU load. I've
On 02/15/12 21:54, Jeff Roberson wrote:
On Wed, 15 Feb 2012, Alexander Motin wrote:
I've decided to stop those cache black magic practices and focus on
things that really exist in this world -- SMT and CPU load. I've
dropped most of cache related things from the patch and made the rest
of things
On 15.02.12 20:47, Alexander Motin wrote:
> On 02/14/12 00:38, Alexander Motin wrote:
>> I see no much point in committing them sequentially, as they are quite
>> orthogonal. I need to make one decision. I am going on small vacation
>> next week. It will give time for thoughts to settle. May be I i
On 02/16/12 10:48, Alexander Motin wrote:
On 02/15/12 21:54, Jeff Roberson wrote:
On Wed, 15 Feb 2012, Alexander Motin wrote:
As before I've tested this on Core i7-870 with 4 physical and 8
logical cores and Atom D525 with 2 physical and 4 logical cores. On
Core i7 I've got speedup up to 10-15%
On 02/15/12 21:54, Jeff Roberson wrote:
On Wed, 15 Feb 2012, Alexander Motin wrote:
As before I've tested this on Core i7-870 with 4 physical and 8
logical cores and Atom D525 with 2 physical and 4 logical cores. On
Core i7 I've got speedup up to 10-15% in super-smack MySQL and
PostgreSQL indexe
On 02/15/12 21:54, Jeff Roberson wrote:
On Wed, 15 Feb 2012, Alexander Motin wrote:
On 02/14/12 00:38, Alexander Motin wrote:
I see no much point in committing them sequentially, as they are quite
orthogonal. I need to make one decision. I am going on small vacation
next week. It will give tim
On Wed, 15 Feb 2012, Alexander Motin wrote:
On 02/14/12 00:38, Alexander Motin wrote:
I see no much point in committing them sequentially, as they are quite
orthogonal. I need to make one decision. I am going on small vacation
next week. It will give time for thoughts to settle. May be I indeed
On 02/15/12 21:54, Jeff Roberson wrote:
On Wed, 15 Feb 2012, Alexander Motin wrote:
As before I've tested this on Core i7-870 with 4 physical and 8
logical cores and Atom D525 with 2 physical and 4 logical cores. On
Core i7 I've got speedup up to 10-15% in super-smack MySQL and
PostgreSQL indexe
On 02/14/12 00:38, Alexander Motin wrote:
I see no much point in committing them sequentially, as they are quite
orthogonal. I need to make one decision. I am going on small vacation
next week. It will give time for thoughts to settle. May be I indeed
just clean previous patch a bit and commit it
On 13.02.2012 23:39, Jeff Roberson wrote:
On Mon, 13 Feb 2012, Alexander Motin wrote:
On 02/13/12 22:23, Jeff Roberson wrote:
On Mon, 13 Feb 2012, Alexander Motin wrote:
On 02/11/12 16:21, Alexander Motin wrote:
I've heavily rewritten the patch already. So at least some of the
ideas
are alre
On Mon, 13 Feb 2012, Alexander Motin wrote:
On 02/13/12 22:23, Jeff Roberson wrote:
On Mon, 13 Feb 2012, Alexander Motin wrote:
On 02/11/12 16:21, Alexander Motin wrote:
I've heavily rewritten the patch already. So at least some of the ideas
are already addressed. :) At this moment I am mos
On 02/13/12 22:23, Jeff Roberson wrote:
On Mon, 13 Feb 2012, Alexander Motin wrote:
On 02/11/12 16:21, Alexander Motin wrote:
I've heavily rewritten the patch already. So at least some of the ideas
are already addressed. :) At this moment I am mostly satisfied with
results and after final test
On Mon, 13 Feb 2012, Alexander Motin wrote:
On 02/11/12 16:21, Alexander Motin wrote:
I've heavily rewritten the patch already. So at least some of the ideas
are already addressed. :) At this moment I am mostly satisfied with
results and after final tests today I'll probably publish new version
On 02/11/12 16:21, Alexander Motin wrote:
I've heavily rewritten the patch already. So at least some of the ideas
are already addressed. :) At this moment I am mostly satisfied with
results and after final tests today I'll probably publish new version.
It took more time, but finally I think I'v
on 11/02/2012 15:35 Andriy Gapon said the following:
> It seems that on modern CPUs the caches are either inclusive or some smart "as
> if inclusive" caches. As a result, if two cores have a shared cache at any
> level, then it should be relatively cheap to move a thread from one core to
> the
>
On Sat, Feb 11, 2012 at 04:21:25PM +0200, Alexander Motin wrote:
> At this moment I am using different penalty coefficients for SMT and
> shared caches (for unrelated processes sharing is is not good). No
> problem to add more types there. Separate flag for shared FPU could be
> used to have dif
On 02/11/12 15:35, Andriy Gapon wrote:
on 06/02/2012 09:04 Alexander Motin said the following:
I've analyzed scheduler behavior and think found the problem with HTT. SCHED_ULE
knows about HTT and when doing load balancing once a second, it does right
things. Unluckily, if some other thread gets
on 06/02/2012 09:04 Alexander Motin said the following:
> Hi.
>
> I've analyzed scheduler behavior and think found the problem with HTT.
> SCHED_ULE
> knows about HTT and when doing load balancing once a second, it does right
> things. Unluckily, if some other thread gets in the way, process can
On 06/02/2012 20:10, Alexander Best wrote:
btw: does anybody know, if there are plans to commit the BFS scheduler to HEAD
BFS is available but I think it needs more work on it before it can be
useful; it didn't explore some optimizations it could have and currently
spends much more time in l
On 2/6/12 11:10 AM, Alexander Best wrote:
On Mon Feb 6 12, Alexander Motin wrote:
On 02/06/12 19:37, Tijl Coosemans wrote:
On Monday 06 February 2012 17:29:14 Alexander Motin wrote:
On 02/06/12 18:01, Alexander Best wrote:
On Mon Feb 6 12, Alexander Motin wrote:
I've analyzed scheduler beh
On 02/06/12 21:08, Florian Smeets wrote:
On 06.02.12 08:59, David Xu wrote:
On 2012/2/6 15:44, Alexander Motin wrote:
On 06.02.2012 09:40, David Xu wrote:
On 2012/2/6 15:04, Alexander Motin wrote:
Hi.
I've analyzed scheduler behavior and think found the problem with HTT.
SCHED_ULE knows abou
On Mon Feb 6 12, Alexander Motin wrote:
> On 02/06/12 19:37, Tijl Coosemans wrote:
> >On Monday 06 February 2012 17:29:14 Alexander Motin wrote:
> >>On 02/06/12 18:01, Alexander Best wrote:
> >>>On Mon Feb 6 12, Alexander Motin wrote:
> I've analyzed scheduler behavior and think found the pro
On 06.02.12 08:59, David Xu wrote:
> On 2012/2/6 15:44, Alexander Motin wrote:
>> On 06.02.2012 09:40, David Xu wrote:
>>> On 2012/2/6 15:04, Alexander Motin wrote:
Hi.
I've analyzed scheduler behavior and think found the problem with HTT.
SCHED_ULE knows about HTT and when doin
On Monday 06 February 2012 17:29:14 Alexander Motin wrote:
> On 02/06/12 18:01, Alexander Best wrote:
>> On Mon Feb 6 12, Alexander Motin wrote:
>>> I've analyzed scheduler behavior and think found the problem with HTT.
>>> SCHED_ULE knows about HTT and when doing load balancing once a second,
>>>
On 02/06/12 19:37, Tijl Coosemans wrote:
On Monday 06 February 2012 17:29:14 Alexander Motin wrote:
On 02/06/12 18:01, Alexander Best wrote:
On Mon Feb 6 12, Alexander Motin wrote:
I've analyzed scheduler behavior and think found the problem with HTT.
SCHED_ULE knows about HTT and when doing
On 02/06/12 18:01, Alexander Best wrote:
On Mon Feb 6 12, Alexander Motin wrote:
I've analyzed scheduler behavior and think found the problem with HTT.
SCHED_ULE knows about HTT and when doing load balancing once a second,
it does right things. Unluckily, if some other thread gets in the way,
p
On Mon Feb 6 12, Alexander Motin wrote:
> Hi.
>
> I've analyzed scheduler behavior and think found the problem with HTT.
> SCHED_ULE knows about HTT and when doing load balancing once a second,
> it does right things. Unluckily, if some other thread gets in the way,
> process can be easily pus
On Mon, 06 Feb 2012 09:04:31 +0200
Alexander Motin wrote:
> I've analyzed scheduler behavior and think found the problem with HTT.
> SCHED_ULE knows about HTT and when doing load balancing once a second,
> it does right things. Unluckily, if some other thread gets in the way,
> process can be
On 2012/2/6 15:44, Alexander Motin wrote:
On 06.02.2012 09:40, David Xu wrote:
On 2012/2/6 15:04, Alexander Motin wrote:
Hi.
I've analyzed scheduler behavior and think found the problem with HTT.
SCHED_ULE knows about HTT and when doing load balancing once a second,
it does right things. Unluc
Hi.
I've analyzed scheduler behavior and think found the problem with HTT.
SCHED_ULE knows about HTT and when doing load balancing once a second,
it does right things. Unluckily, if some other thread gets in the way,
process can be easily pushed out to another CPU, where it will stay for
anot
67 matches
Mail list logo
