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
deviation of only about 5 seconds. It is the same deviation as I see
caused
by only scheduling of 16 threads on 8 cores without any balancing
needed
at
all. 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 patc
should. With 9 threads I see
regular
and random load move between all 8 CPUs. Measurements on 5 minutes run
show
deviation of only about 5 seconds. It is the same deviation as I see
caused
by only scheduling of 16 threads on 8 cores without any balancing
needed
at
all. So I believe this code works a
gt;> as well.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I haven't got good idea yet about balancing priorities, but I've
>>>>>> rewritten
>>>>>> balancer itself. As soon as sched_lowest() / sched_
un
show
deviation of only about 5 seconds. It is the same deviation as I see
caused
by only scheduling of 16 threads on 8 cores without any balancing needed
at
all. 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 f
>>>> intelligent now, they allowed to remove topology traversing from the
>>>> balancer itself. That should fix double-swapping problem, allow to keep
>>>> some
>>>> affinity while moving threads and make balancing more fair. I did number
>>>
s the same deviation as I see
caused
by only scheduling of 16 threads on 8 cores without any balancing needed
at
all. 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 this series (more to come :)) and if
eep
>>> some
>>> affinity while moving threads and make balancing more fair. I did number
>>> of
>>> tests running 4, 8, 9 and 16 CPU-bound threads on 8 CPUs. With 4, 8 and
>>> 16
>>> threads everything is stationary as it should. With 9 threads I see
>>
cing more fair. I did number of
> tests running 4, 8, 9 and 16 CPU-bound threads on 8 CPUs. With 4, 8 and 16
> threads everything is stationary as it should. With 9 threads I see regular
> and random load move between all 8 CPUs. Measurements on 5 minutes run show
> deviation of only ab
as it should. With 9 threads I see regular
and random load move between all 8 CPUs. Measurements on 5 minutes run show
deviation of only about 5 seconds. It is the same deviation as I see caused
by only scheduling of 16 threads on 8 cores without any balancing needed at
all. So I believe this cod
n 5 minutes run show deviation of only about 5 seconds. It
is the same deviation as I see caused by only scheduling of 16 threads
on 8 cores without any balancing needed at all. So I believe this code
works as it should.
Here is the patch: http://people.freebsd.org/~mav/sched.htt40.patch
I pla
2011/1/14 John Baldwin :
> Note that as a result of these
> changes, rtprio threads will no longer share priorities with interactive
> timeshare threads. Instead, rtprio threads are now always more important than
> non-rt threads.
Great!
I was thinking about the split of timesharing threads and
On Friday, January 14, 2011 12:22:18 pm Daniel Eischen wrote:
> On Fri, 14 Jan 2011, John Baldwin wrote:
>
> > This is just a heads up that I've committed some changes to how the
> > scheduler
> > handles realtime thread priorities. Please let me know of any issues you
> > encounter with nice, r
On Fri, 14 Jan 2011, John Baldwin wrote:
This is just a heads up that I've committed some changes to how the scheduler
handles realtime thread priorities. Please let me know of any issues you
encounter with nice, rtprio, or idprio. Note that as a result of these
changes, rtprio threads will no
This is just a heads up that I've committed some changes to how the scheduler
handles realtime thread priorities. Please let me know of any issues you
encounter with nice, rtprio, or idprio. Note that as a result of these
changes, rtprio threads will no longer share priorities with interactive
On Fri, Nov 19, 2010 at 5:27 PM, Oliver Pinter wrote:
> My desktop running 7-STABLE with 100Hz and NOPREEMPT (it's a 4core SMP
> system),
> I tested 8-STABLE, but that is not too responsive, the solution is:
> 100Hz NOPREEMPT + kern.sched.preempt_thresh=224
> After this setting, the system is lik
My desktop running 7-STABLE with 100Hz and NOPREEMPT (it's a 4core SMP system),
I tested 8-STABLE, but that is not too responsive, the solution is:
100Hz NOPREEMPT + kern.sched.preempt_thresh=224
After this setting, the system is likely responsive as 7-STABLE.
On 11/19/10, Garrett Cooper wrote:
>
On 11/19/10 16:49, Taku YAMAMOTO wrote:
I have a dumb local hack to grant ts_slice proportional to the duration
the waking thread slept rather than unconditionally reset to sched_slice.
--- sys/kern/sched_ule.c.orig
+++ sys/kern/sched_ule.c
@@ -1928,12 +1928,16 @@ sched_wakeup(struct thread *t
witch to them on the fly
> > 17:52 @ arundel : wow. that sounds cool. too bad it didn't make it
> > into src tree. by now it's probably outdated and needs to be reworked quite
> > a bit.
> >
> >
> > does anybody know something about this?
>
On Fri, Nov 19, 2010 at 1:10 PM, Oliver Pinter wrote:
> http://lkml.org/lkml/2010/11/16/392
>
> On 11/18/10, O. Hartmann wrote:
>> On 11/18/10 02:30, grarpamp wrote:
>>> Just documenting regarding interactive performance things.
>>> This one's from Linux.
>>>
>>> http://www.phoronix.com/scan.php?
http://lkml.org/lkml/2010/11/16/392
On 11/18/10, O. Hartmann wrote:
> On 11/18/10 02:30, grarpamp wrote:
>> Just documenting regarding interactive performance things.
>> This one's from Linux.
>>
>> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1
>
> Well,
> it would be
On Thu, 18 Nov 2010 21:30:16 +0100
"O. Hartmann" wrote:
> On 11/18/10 19:55, Lucius Windschuh wrote:
> > 2010/11/18 Andriy Gapon:
> >> [Grouping of processes into TTY groups]
> >>
> >> Well, I think that those improvements apply only to a very specific usage
> >> pattern
> >> and are greatly ove
On Fri, Nov 19, 2010 at 02:18:52PM +, Vincent Hoffman wrote:
> On 19/11/2010 12:42, Eric Masson wrote:
> > Bruce Cran writes:
> >
> > Hello,
> >
> >> Google suggests that the work was a GSoC project in 2005 on a pluggable
> >> disk scheduler.
> > It seems that something similar has found its w
On 19/11/2010 12:42, Eric Masson wrote:
> Bruce Cran writes:
>
> Hello,
>
>> Google suggests that the work was a GSoC project in 2005 on a pluggable
>> disk scheduler.
> It seems that something similar has found its way in DFlyBSD, dsched.
And indeed to FreeBSD, man gsched. Added sometime round Ap
Bruce Cran writes:
Hello,
> Google suggests that the work was a GSoC project in 2005 on a pluggable
> disk scheduler.
It seems that something similar has found its way in DFlyBSD, dsched.
Éric Masson
--
manquerait plus que les groupes soient pollués. c'est beaucoup plus
grave que des plage
a group share some characteristic and some
> amount
> of resources.
>
> We stripped the KSEG out of the picture because it really complicated the
> picture.
Yes, unfortunately.
One can think about a number of applications for hierarchical schedulable
resources. Even one-level group
make it
into src \
tree. by now it's probably outdated and needs to be reworked quite a bit.
does anybody know something about this?
I'm aware of the I/O scheduling code (which is now available at least
in -current), but I do not remember CPU scheduling code from Luigi.
On Fri, 19 Nov 2010 00:17:10 +
Alexander Best wrote:
> 17:51 @ Genesys : Luigi Rizzo had a plugabble scheduler back in 4.*
> or \ thereabouts
> 17:51 @ Genesys : you could kldload new ones and switch to them on
> the fly 17:52 @ arundel : wow. that sounds cool. too bad it didn't
> make it
rnel` and FreeBSD's interactivity seems far from
>>> perfect.
>>
>> One thing that just begs to be asked: since when decoding 1080p became
>> an interactive task?
>>
>
> Strictly speaking it isn't - but displaying it is a timing-sensitive
> task th
on 18/11/2010 20:56 Alexander Best said the following:
> On Thu Nov 18 10, Matthew D. Fuller wrote:
>> On Thu, Nov 18, 2010 at 06:23:24PM + I heard the voice of
>> Alexander Best, and lo! it spake thus:
>>>
>>> judging from the videos the changes are having a huge impact imo.
>>
>> Well, my (ad
On Thu, Nov 18, 2010 at 06:23:24PM +, Alexander Best wrote:
> you think so? judging from the videos the changes are having a huge impact
> imo.
On Linux. Have you ever seen those sorts of UI problems on FreeBSD? I don't
watch much video on my systems, but I haven't seen that. FreeBSD has a
On Nov 18, 2010, at 18:43, Julian Elischer wrote:
we are part of the way there..
at least we did abstract the scheduler to the point where we have
two completely different ones. you are welcome to develop a
'framework as you describe and plug it into the abstraction we
already have.
It
maybe that's just them catching up to
> >>>>>where we already are ;)
> >>>>well...i tried playing back a 1080p vide files while doing
> >>>>`make -j64 buildkernel` and FreeBSD's interactivity seems far from
> >>>>perfect.
>
Strictly speaking it isn't - but displaying it is a timing-sensitive
task that isn't CPU- or I/O-bound, and scheduling-wise that probably
makes it more like the "fast response when woken up" interactive tasks
than a CPU-bound non-interactive process.
Decoding it into another fi
ack a 1080p vide files while doing
> >> `make -j64 buildkernel` and FreeBSD's interactivity seems far from
> >> perfect.
> >
> > One thing that just begs to be asked: since when decoding 1080p became
> > an interactive task?
> >
>
> Strictly speaking
On Thu, Nov 18, 2010 at 3:12 PM, Steve Kargl
wrote:
> On Thu, Nov 18, 2010 at 10:59:43PM +, Alexander Best wrote:
>>
>> well i did exactly what they did in the video. watch a 1080p video and move
>> the output window around while compiling the kernel.
>>
>
> It is trivial to bring ULE to its k
On Thu, Nov 18, 2010 at 10:59:43PM +, Alexander Best wrote:
>
> well i did exactly what they did in the video. watch a 1080p video and move
> the output window around while compiling the kernel.
>
It is trivial to bring ULE to its knees. If you
have N cores then all you need is N+1 cpu int
On Thu Nov 18 10, Alexander Kabaev wrote:
> On Thu, 18 Nov 2010 18:56:35 +
> Alexander Best wrote:
>
> > On Thu Nov 18 10, Matthew D. Fuller wrote:
> > > On Thu, Nov 18, 2010 at 06:23:24PM + I heard the voice of
> > > Alexander Best, and lo! it spake thus:
> > > >
> > > > judging from th
gt; perfect.
>
> One thing that just begs to be asked: since when decoding 1080p became
> an interactive task?
>
Strictly speaking it isn't - but displaying it is a timing-sensitive
task that isn't CPU- or I/O-bound, and scheduling-wise that probably
makes it more like the
On Thu, 18 Nov 2010 18:56:35 +
Alexander Best wrote:
> On Thu Nov 18 10, Matthew D. Fuller wrote:
> > On Thu, Nov 18, 2010 at 06:23:24PM + I heard the voice of
> > Alexander Best, and lo! it spake thus:
> > >
> > > judging from the videos the changes are having a huge impact imo.
> >
>
On 11/18/10 19:55, Lucius Windschuh wrote:
2010/11/18 Andriy Gapon:
[Grouping of processes into TTY groups]
Well, I think that those improvements apply only to a very specific usage
pattern
and are greatly over-hyped.
But there are serious issue if you use FreeBSD as a desktop OS with
SMP an
On 11/18/10 19:28, Matthew D. Fuller wrote:
On Thu, Nov 18, 2010 at 06:23:24PM + I heard the voice of
Alexander Best, and lo! it spake thus:
judging from the videos the changes are having a huge impact imo.
Well, my (admittedly limited, and certainly anecdotal) experience is
that Linux's
On 11/18/10 10:55 AM, Lucius Windschuh wrote:
2010/11/18 Andriy Gapon:
[Grouping of processes into TTY groups]
Well, I think that those improvements apply only to a very specific usage
pattern
and are greatly over-hyped.
But there are serious issue if you use FreeBSD as a desktop OS with
SMP
evaluated for freebsd. in this particular case
> it seems linux now does better than freebsd.
Maybe I'm just a lowly user and don't fully understand the issue, but
isn't this the whole reason for having /usr/bin/nice installed?
As in, if you don't want your make job to hog
On Nov 18, 2010, at 10:23 AM, Alexander Best wrote:
> On Thu Nov 18 10, Andriy Gapon wrote:
>> on 18/11/2010 13:04 O. Hartmann said the following:
>>> On 11/18/10 02:30, grarpamp wrote:
Just documenting regarding interactive performance things.
This one's from Linux.
http://www
2010/11/18 Andriy Gapon :
> [Grouping of processes into TTY groups]
>
> Well, I think that those improvements apply only to a very specific usage
> pattern
> and are greatly over-hyped.
But there are serious issue if you use FreeBSD as a desktop OS with
SMP and SCHED_ULE, or?
Because currently, m
On Thu Nov 18 10, Rob Farmer wrote:
> On Thu, Nov 18, 2010 at 10:39, Chuck Swiger wrote:
> > Frankly, I'm also turned off by the attempt to popup a full page ad in
> > addition to the rest of the advertising content which surrounds what is
> > nominally supposed to be the real content. That doe
On Thu Nov 18 10, Matthew D. Fuller wrote:
> On Thu, Nov 18, 2010 at 06:23:24PM + I heard the voice of
> Alexander Best, and lo! it spake thus:
> >
> > judging from the videos the changes are having a huge impact imo.
>
> Well, my (admittedly limited, and certainly anecdotal) experience is
>
On Thu, Nov 18, 2010 at 06:23:24PM + I heard the voice of
Alexander Best, and lo! it spake thus:
>
> judging from the videos the changes are having a huge impact imo.
Well, my (admittedly limited, and certainly anecdotal) experience is
that Linux's interactive response when under heavy load w
On Thu, Nov 18, 2010 at 10:39, Chuck Swiger wrote:
> Frankly, I'm also turned off by the attempt to popup a full page ad in
> addition to the rest of the advertising content which surrounds what is
> nominally supposed to be the real content. That doesn't mean there is
> anything wrong with th
On Thu Nov 18 10, Andriy Gapon wrote:
> on 18/11/2010 13:04 O. Hartmann said the following:
> > On 11/18/10 02:30, grarpamp wrote:
> >> Just documenting regarding interactive performance things.
> >> This one's from Linux.
> >>
> >> http://www.phoronix.com/scan.php?page=article&item=linux_2637_vide
on 18/11/2010 13:04 O. Hartmann said the following:
> On 11/18/10 02:30, grarpamp wrote:
>> Just documenting regarding interactive performance things.
>> This one's from Linux.
>>
>> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1
>
> Well,
> it would be nice to have thos
On 11/18/10 02:30, grarpamp wrote:
Just documenting regarding interactive performance things.
This one's from Linux.
http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1
Well,
it would be nice to have those improvements in FreeBSD, but I doubt this
will make it in due tim
Alexander Motin wrote:
> Takanori Watanabe wrote:
>> I updated my FreeBSD tree on laptop, to the current
>> as of 18 Oct.2010, it works fine with CPU C3 state enabled,
>>
>> I think this is your achievement of event time scheduler,
>> thanks!
>>
>> But when USB driver is enabled, the load average i
On Wednesday 27 October 2010 10:14:18 Alexander Motin wrote:
> As I understand, if respective USB port is not used, USB stack should
> put it into power_save mode not poll so often to deny entering C3 state.
USB will stop the hardware from polling RAM, but still a 4 second root HUB
software timer
Quoting Alexander Motin (from Tue, 26 Oct 2010
22:57:59 +0300):
Takanori Watanabe wrote:
It's time to implement powertop for freebsd, isn't it?
Surely it is. I was even thinking about possibility to port one from
OpenSolaris, but other work distracted me. You may take it, it you wish.
Nate Lawson wrote:
> On 10/26/2010 12:57 PM, Alexander Motin wrote:
>> Takanori Watanabe wrote:
>>> I updated my FreeBSD tree on laptop, to the current
>>> as of 18 Oct.2010, it works fine with CPU C3 state enabled,
>>>
>>> I think this is your achievement of event time scheduler,
>>> thanks!
>
>
By default USB devices are not suspended. You can use "usbconfig power_save"
to enable automatic power save for all devices.
--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, sen
On 10/26/2010 12:57 PM, Alexander Motin wrote:
> Takanori Watanabe wrote:
>> I updated my FreeBSD tree on laptop, to the current
>> as of 18 Oct.2010, it works fine with CPU C3 state enabled,
>>
>> I think this is your achievement of event time scheduler,
>> thanks!
Ah, so mav@ implemented a tickl
Takanori Watanabe wrote:
> I updated my FreeBSD tree on laptop, to the current
> as of 18 Oct.2010, it works fine with CPU C3 state enabled,
>
> I think this is your achievement of event time scheduler,
> thanks!
>
> But when USB driver is enabled, the load average is considerablly
> high (0.6 t
I updated my FreeBSD tree on laptop, to the current
as of 18 Oct.2010, it works fine with CPU C3 state enabled,
I think this is your achievement of event time scheduler,
thanks!
But when USB driver is enabled, the load average is considerablly
high (0.6 to 1.0) if sysctl oid kern.eventtimer.peri
-current?
libkse?
libthr?
SCHED_ULE?
SCHED_4BSD?
On Thu, 4 Sep 2003, Andy Farkas wrote:
>
> Not to flog a dead horse, but scheduling seems to be very broken this month.
>
> I am subjectively watching my smp box do a:
>
> 'cd /usr/ports/www/apache2 ; make all' in
On Thu, Sep 04, 2003 at 03:24:13AM +1000, Andy Farkas wrote:
>
> Not to flog a dead horse, but scheduling seems to be very broken this month.
>
> I am subjectively watching my smp box do a:
>
> 'cd /usr/ports/www/apache2 ; make all' in one window, and
>
> &
Not to flog a dead horse, but scheduling seems to be very broken this month.
I am subjectively watching my smp box do a:
'cd /usr/ports/www/apache2 ; make all' in one window, and
'cd cd /usr/ports/databases/mysql40-server/ ; make all' in another window,
and most disturbi
In Project
The current UHCI driver constructs the bulk transfer queue as a simple
list with a 'terminate' marker on the end. This means that the bulk queue
runs only once per frame period. This is OK for devices with large input
buffers, but in the case of a large transfer to a device with a small
input b
70 matches
Mail list logo
