Hi,
2012/4/9 Alexander Motin m...@freebsd.org:
[...]
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
On 04/10/12 19:58, Arnaud Lacombe wrote:
2012/4/9 Alexander Motinm...@freebsd.org:
[...]
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
On 04/10/12 20:18, Alexander Motin wrote:
On 04/10/12 19:58, Arnaud Lacombe wrote:
2012/4/9 Alexander Motinm...@freebsd.org:
[...]
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
Hi,
On Tue, Apr 10, 2012 at 1:53 PM, Alexander Motin m...@freebsd.org wrote:
On 04/10/12 20:18, Alexander Motin wrote:
On 04/10/12 19:58, Arnaud Lacombe wrote:
2012/4/9 Alexander Motinm...@freebsd.org:
[...]
I have strong feeling that while this test may be interesting for
profiling,
On 04/10/12 21:46, Arnaud Lacombe wrote:
On Tue, Apr 10, 2012 at 1:53 PM, Alexander Motinm...@freebsd.org wrote:
On 04/10/12 20:18, Alexander Motin wrote:
On 04/10/12 19:58, Arnaud Lacombe wrote:
2012/4/9 Alexander Motinm...@freebsd.org:
I have strong feeling that while this test may be
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 final
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 plan
. 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 as it should.
Here is the patch: http://people.freebsd.org/~mav/sched.htt40.patch
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 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
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 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
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
. 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 patch of this series (more to come
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
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 code works
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 as it should.
Here
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
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
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, rtprio, or
2011/1/14 John Baldwin j...@freebsd.org:
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
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 (admittedly
` 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 that isn't CPU- or I/O-bound, and scheduling-wise that probably
Well, I am
On Fri, 19 Nov 2010 00:17:10 +
Alexander Best arun...@freebsd.org 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
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?
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
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 scheduling could be a very useful subcase
Bruce Cran br...@cran.org.uk 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
On 19/11/2010 12:42, Eric Masson wrote:
Bruce Cran br...@cran.org.uk 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
On Fri, Nov 19, 2010 at 02:18:52PM +, Vincent Hoffman wrote:
On 19/11/2010 12:42, Eric Masson wrote:
Bruce Cran br...@cran.org.uk 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
On Thu, 18 Nov 2010 21:30:16 +0100
O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote:
On 11/18/10 19:55, Lucius Windschuh wrote:
2010/11/18 Andriy Gapona...@freebsd.org:
[Grouping of processes into TTY groups]
Well, I think that those improvements apply only to a very specific usage
http://lkml.org/lkml/2010/11/16/392
On 11/18/10, O. Hartmann ohart...@zedat.fu-berlin.de 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=articleitem=linux_2637_videonum=1
Well,
On Fri, Nov 19, 2010 at 1:10 PM, Oliver Pinter oliver.p...@gmail.com wrote:
http://lkml.org/lkml/2010/11/16/392
On 11/18/10, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
On 11/18/10 02:30, grarpamp wrote:
Just documenting regarding interactive performance things.
This one's from Linux.
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?
I'm aware of the I/O scheduling code (which is now available at least
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
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
On Fri, Nov 19, 2010 at 5:27 PM, Oliver Pinter oliver.p...@gmail.com 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,
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=articleitem=linux_2637_videonum=1
Well,
it would be nice to have those improvements in FreeBSD, but I doubt this
will make it in due time
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=articleitem=linux_2637_videonum=1
Well,
it would be nice to have those
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=articleitem=linux_2637_videonum=1
On Thu, Nov 18, 2010 at 10:39, Chuck Swiger cswi...@mac.com 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
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
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
that
On Thu Nov 18 10, Rob Farmer wrote:
On Thu, Nov 18, 2010 at 10:39, Chuck Swiger cswi...@mac.com 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.
2010/11/18 Andriy Gapon a...@freebsd.org:
[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
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.
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 resources, then use nice
to run it in the background.
How does the work on the geom_sched (for I/O scheduling) play into this?
Am I missing
On 11/18/10 10:55 AM, Lucius Windschuh wrote:
2010/11/18 Andriy Gapona...@freebsd.org:
[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
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 19:55, Lucius Windschuh wrote:
2010/11/18 Andriy Gapona...@freebsd.org:
[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
On Thu, 18 Nov 2010 18:56:35 +
Alexander Best arun...@freebsd.org 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
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 file on the disk is in the latter category,
of course - but I don't
On Thu Nov 18 10, Alexander Kabaev wrote:
On Thu, 18 Nov 2010 18:56:35 +
Alexander Best arun...@freebsd.org 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
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
On Thu, Nov 18, 2010 at 3:12 PM, Steve Kargl
s...@troutmask.apl.washington.edu 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
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 fast response when woken up interactive tasks
than a CPU-bound non-interactive process.
Decoding it into another file
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 fast response when woken up interactive tasks
than a CPU-bound non-interactive process.
Decoding it into another file
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 fast response when woken up interactive tasks
than a CPU-bound non
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
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
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 is
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, send
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!
Ah, so mav@
Quoting Alexander Motin m...@freebsd.org (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
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
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
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 to 1.0)
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
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 disturbingly a 'top -S
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
'cd cd /usr/ports/databases/mysql40-server
-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 one window, and
'cd cd /usr
Scheduling
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
70 matches
Mail list logo
