Re: SCHED_ULE should not be the default

classic Classic list List threaded Threaded
63 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

Hartmann, O.

> Not fully right, boinc defaults to run on idprio 31 so this isn't an
> issue. And yes, there are cases where SCHED_ULE shows much better
> performance then SCHED_4BSD.  [...]

Do we have any proof at hand for such cases where SCHED_ULE performs
much better than SCHED_4BSD? Whenever the subject comes up, it is
mentioned, that SCHED_ULE has better performance on boxes with a ncpu >
2. But in the end I see here contradictionary statements. People
complain about poor performance (especially in scientific environments),
and other give contra not being the case.

Within our department, we developed a highly scalable code for planetary
science purposes on imagery. It utilizes present GPUs via OpenCL if
present. Otherwise it grabs as many cores as it can.
By the end of this year I'll get a new desktop box based on Intels new
Sandy Bridge-E architecture with plenty of memory. If the colleague who
developed the code is willing performing some benchmarks on the same
hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most
recent Suse. For FreeBSD I intent also to look for performance with both
different schedulers available.

O.


signature.asc (300 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

Vincent Hoffman-Kazlauskas

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/12/2011 13:47, O. Hartmann wrote:

>
>> Not fully right, boinc defaults to run on idprio 31 so this isn't an
>> issue. And yes, there are cases where SCHED_ULE shows much better
>> performance then SCHED_4BSD. [...]
>
> Do we have any proof at hand for such cases where SCHED_ULE performs
> much better than SCHED_4BSD? Whenever the subject comes up, it is
> mentioned, that SCHED_ULE has better performance on boxes with a ncpu >
> 2. But in the end I see here contradictionary statements. People
> complain about poor performance (especially in scientific environments),
> and other give contra not being the case.
It all a little old now but some if the stuff in
http://people.freebsd.org/~kris/scaling/
covers improvements that were seen.

http://jeffr-tech.livejournal.com/5705.html
shows a little too, reading though Jeffs blog is worth it as it has some
interesting stuff on SHED_ULE.

I thought there were some more benchmarks floating round but cant find
any with a quick google.


Vince

>
> Within our department, we developed a highly scalable code for planetary
> science purposes on imagery. It utilizes present GPUs via OpenCL if
> present. Otherwise it grabs as many cores as it can.
> By the end of this year I'll get a new desktop box based on Intels new
> Sandy Bridge-E architecture with plenty of memory. If the colleague who
> developed the code is willing performing some benchmarks on the same
> hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most
> recent Suse. For FreeBSD I intent also to look for performance with both
> different schedulers available.
>
> O.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJO5hn7AAoJEF4mgOY1fXowOLAP/2EjhAFPb88NgKM0ieBb4X7R
NSw/9HTiwcshkfEdvYjAzYZ0cUWetEuRfnPVnh+abwfJEmMzZkwA0KIz8UYGHHik
22Z2SWSVDiwZAluz0ca7Xc931ojbzrK/zVMbivqW3cvnz8P4oEnASiENnsoa89Jy
Oskjd4QpAyIpB/AsYgc9FLT3kPX13fXC5bzw/zAPDsaupOYssRRlZu8nnqsEc1i1
IanLIPKLnIbpZTx75ehWxxRW8IjiQRvIe+7eBaDMhXO/Kvftotf0JzknrBnJezDQ
ZdhiOTq7F1Pm3dxra+DNKD+Dw+xUCYPFq/kuyqrZNz44H3qwT60vDhvw0yDz6422
nNP11z2+G4M85sahBak5AmSHuyek7HWb6uIHHnfvwNKSX4ZsdS8MVBViNJjmCYtL
PwuHDU3WdCes/vvKRNDopSp/s6RSLK9w3RT7jlMkaTu2Mmtw0BwGziDJ2pGaCQ14
68R5eO/SfNxoVp0g4lIzObyQR+//0OmALzElVK3VmHM9NoL3qZGCwBRLqjN5re82
dX6nsBr/DFJOpaFfdFLwPNyCNdNpg/WVegRkq2BEL/BaMISNiKzoVbM0Psh9gnb3
LW1j3LP2fOHhuN1bW3S31JmbNzvAnlRNynoNMldrwj5PWJY2HPk+mMFRjmRwdDTJ
9mhscz8++WRPvDZQXefl
=XqaR
-----END PGP SIGNATURE-----

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

Gary Jennejohn-5
On Mon, 12 Dec 2011 15:13:00 +0000
Vincent Hoffman <[hidden email]> wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/12/2011 13:47, O. Hartmann wrote:
> >
> >> Not fully right, boinc defaults to run on idprio 31 so this isn't an
> >> issue. And yes, there are cases where SCHED_ULE shows much better
> >> performance then SCHED_4BSD. [...]
> >
> > Do we have any proof at hand for such cases where SCHED_ULE performs
> > much better than SCHED_4BSD? Whenever the subject comes up, it is
> > mentioned, that SCHED_ULE has better performance on boxes with a ncpu >
> > 2. But in the end I see here contradictionary statements. People
> > complain about poor performance (especially in scientific environments),
> > and other give contra not being the case.
> It all a little old now but some if the stuff in
> http://people.freebsd.org/~kris/scaling/
> covers improvements that were seen.
>
> http://jeffr-tech.livejournal.com/5705.html
> shows a little too, reading though Jeffs blog is worth it as it has some
> interesting stuff on SHED_ULE.
>
> I thought there were some more benchmarks floating round but cant find
> any with a quick google.
>
>
> Vince
>
> >
> > Within our department, we developed a highly scalable code for planetary
> > science purposes on imagery. It utilizes present GPUs via OpenCL if
> > present. Otherwise it grabs as many cores as it can.
> > By the end of this year I'll get a new desktop box based on Intels new
> > Sandy Bridge-E architecture with plenty of memory. If the colleague who
> > developed the code is willing performing some benchmarks on the same
> > hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most
> > recent Suse. For FreeBSD I intent also to look for performance with both
> > different schedulers available.
> >

These observations are not scientific, but I have a CPU from AMD with
6 cores (AMD Phenom(tm) II X6 1090T Processor).

My simple test was ``make buildkernel'' while watching the core usage with
gkrellm.

With SCHED_4BSD all 6 cores are loaded to 97% during the build phase.
I've never seen any value above 97% with gkrellm.

With SCHED_ULE I never saw all 6 cores loaded this heavily.  Usually
2 or more cores were at or below 90%.  Not really that significant, but
still a noticeable difference in apparent scheduling behavior.  Whether
the observed difference is due to some change in data from the kernel to
gkrellm is beyond me.

--
Gary Jennejohn
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

Steve Kargl
In reply to this post by Hartmann, O.
On Mon, Dec 12, 2011 at 02:47:57PM +0100, O. Hartmann wrote:

>
> > Not fully right, boinc defaults to run on idprio 31 so this isn't an
> > issue. And yes, there are cases where SCHED_ULE shows much better
> > performance then SCHED_4BSD.  [...]
>
> Do we have any proof at hand for such cases where SCHED_ULE performs
> much better than SCHED_4BSD? Whenever the subject comes up, it is
> mentioned, that SCHED_ULE has better performance on boxes with a ncpu >
> 2. But in the end I see here contradictionary statements. People
> complain about poor performance (especially in scientific environments),
> and other give contra not being the case.
>
> Within our department, we developed a highly scalable code for planetary
> science purposes on imagery. It utilizes present GPUs via OpenCL if
> present. Otherwise it grabs as many cores as it can.
> By the end of this year I'll get a new desktop box based on Intels new
> Sandy Bridge-E architecture with plenty of memory. If the colleague who
> developed the code is willing performing some benchmarks on the same
> hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most
> recent Suse. For FreeBSD I intent also to look for performance with both
> different schedulers available.
>

This comes up every 9 months or so, and must be approaching
FAQ status.

In a HPC environment, I recommend 4BSD.  Depending on
the workload, ULE can cause a severe increase in turn
around time when doing already long computations.  If
you have an MPI application, simply launching greater
than ncpu+1 jobs can show the problem.

PS: search the list archives for "kargl and ULE".

--
Steve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

Pieter de Goeje
In reply to this post by Hartmann, O.
On Monday 12 December 2011 14:47:57 O. Hartmann wrote:

> > Not fully right, boinc defaults to run on idprio 31 so this isn't an
> > issue. And yes, there are cases where SCHED_ULE shows much better
> > performance then SCHED_4BSD.  [...]
>
> Do we have any proof at hand for such cases where SCHED_ULE performs
> much better than SCHED_4BSD? Whenever the subject comes up, it is
> mentioned, that SCHED_ULE has better performance on boxes with a ncpu >
> 2. But in the end I see here contradictionary statements. People
> complain about poor performance (especially in scientific environments),
> and other give contra not being the case.
>
> Within our department, we developed a highly scalable code for planetary
> science purposes on imagery. It utilizes present GPUs via OpenCL if
> present. Otherwise it grabs as many cores as it can.
> By the end of this year I'll get a new desktop box based on Intels new
> Sandy Bridge-E architecture with plenty of memory. If the colleague who
> developed the code is willing performing some benchmarks on the same
> hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most
> recent Suse. For FreeBSD I intent also to look for performance with both
> different schedulers available.
>
> O.

In my spare time I do some stuff which can be considered "HPC". If I recall
correctly the most loud supporters of the notion that SCHED_BSD is faster
than SCHED_ULE are using more threads than there are cores, causing CPU core
contention and more importantly unevenly distributed runtimes among threads,
resulting in suboptimal execution times for their programs. Since I've never
actually seen that code in question it's hard to say whether or not
this "unfair" distribution actually results in lower throughput or that it
simply violates an assumption in the code that each thread takes about as
long to finish its task.
Although I haven't actually benchmarked the two schedulers directly, I have no
reason to suspect SCHED_ULE of suboptimal performance because:
1) A program model where there are N threads on N cores which take work items
from a shared queue until it is empty has almost perfect scaling on SCHED_ULE
(I get 398% CPU usage on a quadcore)
2) The same program on Linux (dual boot) compiled with exactly the same
compiler and flags runs slightly slower. I think this has to do with VM
differences.

What I'm trying to say is that until someone actually shows some code which
has demonstrably lower performance on SCHED_ULE and this is not caused by
IMHO improper timing dependencies between threads I'd say that there is no
cause for concern here. I actually expect performance differences between the
two schedulers to show in problems which cause a lot more contention on the
CPU cores and use lots of locks internally so threads are frequently waiting
on each other, for instance the MySQL benchmarks done a couple of years ago
by Kris Kennaway.

Aside from algorithmic limitations (SCHED_BSD doesn't really scale all that
well), there will always exist some problems in which SCHED_BSD is faster
because it by chance has a better execution order for these problems... The
good thing is people have a choice :-).

I'm looking forward to the results of your benchmark.

--
Pieter de Goeje
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

mdf-2
In reply to this post by Gary Jennejohn-5
On Mon, Dec 12, 2011 at 7:32 AM, Gary Jennejohn
<[hidden email]> wrote:

> On Mon, 12 Dec 2011 15:13:00 +0000
> Vincent Hoffman <[hidden email]> wrote:
>
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 12/12/2011 13:47, O. Hartmann wrote:
>> >
>> >> Not fully right, boinc defaults to run on idprio 31 so this isn't an
>> >> issue. And yes, there are cases where SCHED_ULE shows much better
>> >> performance then SCHED_4BSD. [...]
>> >
>> > Do we have any proof at hand for such cases where SCHED_ULE performs
>> > much better than SCHED_4BSD? Whenever the subject comes up, it is
>> > mentioned, that SCHED_ULE has better performance on boxes with a ncpu >
>> > 2. But in the end I see here contradictionary statements. People
>> > complain about poor performance (especially in scientific environments),
>> > and other give contra not being the case.
>> It all a little old now but some if the stuff in
>> http://people.freebsd.org/~kris/scaling/
>> covers improvements that were seen.
>>
>> http://jeffr-tech.livejournal.com/5705.html
>> shows a little too, reading though Jeffs blog is worth it as it has some
>> interesting stuff on SHED_ULE.
>>
>> I thought there were some more benchmarks floating round but cant find
>> any with a quick google.
>>
>>
>> Vince
>>
>> >
>> > Within our department, we developed a highly scalable code for planetary
>> > science purposes on imagery. It utilizes present GPUs via OpenCL if
>> > present. Otherwise it grabs as many cores as it can.
>> > By the end of this year I'll get a new desktop box based on Intels new
>> > Sandy Bridge-E architecture with plenty of memory. If the colleague who
>> > developed the code is willing performing some benchmarks on the same
>> > hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most
>> > recent Suse. For FreeBSD I intent also to look for performance with both
>> > different schedulers available.
>> >
>
> These observations are not scientific, but I have a CPU from AMD with
> 6 cores (AMD Phenom(tm) II X6 1090T Processor).
>
> My simple test was ``make buildkernel'' while watching the core usage with
> gkrellm.
>
> With SCHED_4BSD all 6 cores are loaded to 97% during the build phase.
> I've never seen any value above 97% with gkrellm.
>
> With SCHED_ULE I never saw all 6 cores loaded this heavily.  Usually
> 2 or more cores were at or below 90%.  Not really that significant, but
> still a noticeable difference in apparent scheduling behavior.  Whether
> the observed difference is due to some change in data from the kernel to
> gkrellm is beyond me.

SCHED_ULE is much sloppier about calculating which thread used a
timeslice -- unless the timeslice went 100% to a thread, the fraction
it used may get attributed elsewhere.  So top's reporting of thread
usage is not a useful metric.  Total buildworld time is, potentially.

Thanks,
matthew
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

Lars Engels-2
In reply to this post by Gary Jennejohn-5
Did you use -jX to build the world?

_____________________________________________
Von: Gary Jennejohn <[hidden email]>
Versendet am: Mon Dec 12 16:32:21 MEZ 2011
An: Vincent Hoffman <[hidden email]>
CC: "O. Hartmann" <[hidden email]>, Current FreeBSD <[hidden email]>, [hidden email], [hidden email]
Betreff: Re: SCHED_ULE should not be the default


On Mon, 12 Dec 2011 15:13:00 +0000
Vincent Hoffman <[hidden email]> wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/12/2011 13:47, O. Hartmann wrote:
> >
> >> Not fully right, boinc defaults to run on idprio 31 so this isn't an
> >> issue. And yes, there are cases where SCHED_ULE shows much better
> >> performance then SCHED_4BSD. [...]
> >
> > Do we have any proof at hand for such cases where SCHED_ULE performs
> > much better than SCHED_4BSD? Whenever the subject comes up, it is
> > mentioned, that SCHED_ULE has better performance on boxes with a ncpu >
> > 2. But in the end I see here contradictionary statements. People
> > complain about poor performance (especially in scientific environments),
> > and other give contra not being the case.
> It all a little old now but some if the stuff in
> http://people.freebsd.org/~kris/scaling/
> covers improvements that were seen.
>
> http://jeffr-tech.livejournal.com/5705.html
> shows a little too, reading though Jeffs blog is worth it as it has some
> interesting stuff on SHED_ULE.
>
> I thought there were some more benchmarks floating round but cant find
> any with a quick google.
>
>
> Vince
>
> >
> > Within our department, we developed a highly scalable code for planetary
> > science purposes on imagery. It utilizes present GPUs via OpenCL if
> > present. Otherwise it grabs as many cores as it can.
> > By the end of this year I'll get a new desktop box based on Intels new
> > Sandy Bridge-E architecture with plenty of memory. If the colleague who
> > developed the code is willing performing some benchmarks on the same
> > hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most
> > recent Suse. For FreeBSD I intent also to look for performance with both
> > different schedulers available.
> >

These observations are not scientific, but I have a CPU from AMD with
6 cores (AMD Phenom(tm) II X6 1090T Processor).

My simple test was ``make buildkernel'' while watching the core usage with
gkrellm.

With SCHED_4BSD all 6 cores are loaded to 97% during the build phase.
I've never seen any value above 97% with gkrellm.

With SCHED_ULE I never saw all 6 cores loaded this heavily. Usually
2 or more cores were at or below 90%. Not really that significant, but
still a noticeable difference in apparent scheduling behavior. Whether
the observed difference is due to some change in data from the kernel to
gkrellm is beyond me.

--
Gary Jennejohn
_____________________________________________

[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

Lars Engels-2
In reply to this post by Steve Kargl
Would it be possible to implement a mechanism that lets one change the scheduler on the fly? Afaik Solaris can do that.

_____________________________________________
Von: Steve Kargl <[hidden email]>
Versendet am: Mon Dec 12 16:51:59 MEZ 2011
An: "O. Hartmann" <[hidden email]>
CC: [hidden email], Current FreeBSD <[hidden email]>, [hidden email]
Betreff: Re: SCHED_ULE should not be the default


On Mon, Dec 12, 2011 at 02:47:57PM +0100, O. Hartmann wrote:

>
> > Not fully right, boinc defaults to run on idprio 31 so this isn't an
> > issue. And yes, there are cases where SCHED_ULE shows much better
> > performance then SCHED_4BSD. [...]
>
> Do we have any proof at hand for such cases where SCHED_ULE performs
> much better than SCHED_4BSD? Whenever the subject comes up, it is
> mentioned, that SCHED_ULE has better performance on boxes with a ncpu >
> 2. But in the end I see here contradictionary statements. People
> complain about poor performance (especially in scientific environments),
> and other give contra not being the case.
>
> Within our department, we developed a highly scalable code for planetary
> science purposes on imagery. It utilizes present GPUs via OpenCL if
> present. Otherwise it grabs as many cores as it can.
> By the end of this year I'll get a new desktop box based on Intels new
> Sandy Bridge-E architecture with plenty of memory. If the colleague who
> developed the code is willing performing some benchmarks on the same
> hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most
> recent Suse. For FreeBSD I intent also to look for performance with both
> different schedulers available.
>

This comes up every 9 months or so, and must be approaching
FAQ status.

In a HPC environment, I recommend 4BSD. Depending on
the workload, ULE can cause a severe increase in turn
around time when doing already long computations. If
you have an MPI application, simply launching greater
than ncpu+1 jobs can show the problem.

PS: search the list archives for "kargl and ULE".

--
Steve
_____________________________________________

[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

Bruce Cran
In reply to this post by Steve Kargl
On 12/12/2011 15:51, Steve Kargl wrote:
> This comes up every 9 months or so, and must be approaching FAQ
> status. In a HPC environment, I recommend 4BSD. Depending on the
> workload, ULE can cause a severe increase in turn around time when
> doing already long computations. If you have an MPI application,
> simply launching greater than ncpu+1 jobs can show the problem. PS:
> search the list archives for "kargl and ULE".

This isn't something that can be fixed by tuning ULE? For example for
desktop applications kern.sched.preempt_thresh should be set to 224 from
its default. I'm wondering if the installer should ask people what the
typical use will be, and tune the scheduler appropriately.

--
Bruce Cran
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

Ivan Klymenko
В Mon, 12 Dec 2011 16:18:35 +0000
Bruce Cran <[hidden email]> пишет:

> On 12/12/2011 15:51, Steve Kargl wrote:
> > This comes up every 9 months or so, and must be approaching FAQ
> > status. In a HPC environment, I recommend 4BSD. Depending on the
> > workload, ULE can cause a severe increase in turn around time when
> > doing already long computations. If you have an MPI application,
> > simply launching greater than ncpu+1 jobs can show the problem. PS:
> > search the list archives for "kargl and ULE".
>
> This isn't something that can be fixed by tuning ULE? For example for
> desktop applications kern.sched.preempt_thresh should be set to 224
> from its default. I'm wondering if the installer should ask people
> what the typical use will be, and tune the scheduler appropriately.
>

This is by and large does not help in certain situations ...
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

Gary Jennejohn-5
In reply to this post by Lars Engels-2
On Mon, 12 Dec 2011 17:10:46 +0100
Lars Engels <[hidden email]> wrote:

> Did you use -jX to build the world?
>

I'm top posting since Lars did.

It was buildkernel, not buildworld.

Yes, -j6.

> _____________________________________________
> Von: Gary Jennejohn <[hidden email]>
> Versendet am: Mon Dec 12 16:32:21 MEZ 2011
> An: Vincent Hoffman <[hidden email]>
> CC: "O. Hartmann" <[hidden email]>, Current FreeBSD <[hidden email]>, [hidden email], [hidden email]
> Betreff: Re: SCHED_ULE should not be the default
>
>
> On Mon, 12 Dec 2011 15:13:00 +0000
> Vincent Hoffman <[hidden email]> wrote:
>
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 12/12/2011 13:47, O. Hartmann wrote:
> > >
> > >> Not fully right, boinc defaults to run on idprio 31 so this isn't an
> > >> issue. And yes, there are cases where SCHED_ULE shows much better
> > >> performance then SCHED_4BSD. [...]
> > >
> > > Do we have any proof at hand for such cases where SCHED_ULE performs
> > > much better than SCHED_4BSD? Whenever the subject comes up, it is
> > > mentioned, that SCHED_ULE has better performance on boxes with a ncpu >
> > > 2. But in the end I see here contradictionary statements. People
> > > complain about poor performance (especially in scientific environments),
> > > and other give contra not being the case.
> > It all a little old now but some if the stuff in
> > http://people.freebsd.org/~kris/scaling/
> > covers improvements that were seen.
> >
> > http://jeffr-tech.livejournal.com/5705.html
> > shows a little too, reading though Jeffs blog is worth it as it has some
> > interesting stuff on SHED_ULE.
> >
> > I thought there were some more benchmarks floating round but cant find
> > any with a quick google.
> >
> >
> > Vince
> >
> > >
> > > Within our department, we developed a highly scalable code for planetary
> > > science purposes on imagery. It utilizes present GPUs via OpenCL if
> > > present. Otherwise it grabs as many cores as it can.
> > > By the end of this year I'll get a new desktop box based on Intels new
> > > Sandy Bridge-E architecture with plenty of memory. If the colleague who
> > > developed the code is willing performing some benchmarks on the same
> > > hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most
> > > recent Suse. For FreeBSD I intent also to look for performance with both
> > > different schedulers available.
> > >
>
> These observations are not scientific, but I have a CPU from AMD with
> 6 cores (AMD Phenom(tm) II X6 1090T Processor).
>
> My simple test was ``make buildkernel'' while watching the core usage with
> gkrellm.
>
> With SCHED_4BSD all 6 cores are loaded to 97% during the build phase.
> I've never seen any value above 97% with gkrellm.
>
> With SCHED_ULE I never saw all 6 cores loaded this heavily. Usually
> 2 or more cores were at or below 90%. Not really that significant, but
> still a noticeable difference in apparent scheduling behavior. Whether
> the observed difference is due to some change in data from the kernel to
> gkrellm is beyond me.
>
> --
> Gary Jennejohn
> _____________________________________________
>
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[hidden email]"
>


--
Gary Jennejohn
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

Gary Jennejohn-5
In reply to this post by mdf-2
On Mon, 12 Dec 2011 08:04:37 -0800
[hidden email] wrote:

> On Mon, Dec 12, 2011 at 7:32 AM, Gary Jennejohn
> <[hidden email]> wrote:
> > On Mon, 12 Dec 2011 15:13:00 +0000
> > Vincent Hoffman <[hidden email]> wrote:
> >
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 12/12/2011 13:47, O. Hartmann wrote:
> >> >
> >> >> Not fully right, boinc defaults to run on idprio 31 so this isn't an
> >> >> issue. And yes, there are cases where SCHED_ULE shows much better
> >> >> performance then SCHED_4BSD. [...]
> >> >
> >> > Do we have any proof at hand for such cases where SCHED_ULE performs
> >> > much better than SCHED_4BSD? Whenever the subject comes up, it is
> >> > mentioned, that SCHED_ULE has better performance on boxes with a ncpu >
> >> > 2. But in the end I see here contradictionary statements. People
> >> > complain about poor performance (especially in scientific environments),
> >> > and other give contra not being the case.
> >> It all a little old now but some if the stuff in
> >> http://people.freebsd.org/~kris/scaling/
> >> covers improvements that were seen.
> >>
> >> http://jeffr-tech.livejournal.com/5705.html
> >> shows a little too, reading though Jeffs blog is worth it as it has some
> >> interesting stuff on SHED_ULE.
> >>
> >> I thought there were some more benchmarks floating round but cant find
> >> any with a quick google.
> >>
> >>
> >> Vince
> >>
> >> >
> >> > Within our department, we developed a highly scalable code for planetary
> >> > science purposes on imagery. It utilizes present GPUs via OpenCL if
> >> > present. Otherwise it grabs as many cores as it can.
> >> > By the end of this year I'll get a new desktop box based on Intels new
> >> > Sandy Bridge-E architecture with plenty of memory. If the colleague who
> >> > developed the code is willing performing some benchmarks on the same
> >> > hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most
> >> > recent Suse. For FreeBSD I intent also to look for performance with both
> >> > different schedulers available.
> >> >
> >
> > These observations are not scientific, but I have a CPU from AMD with
> > 6 cores (AMD Phenom(tm) II X6 1090T Processor).
> >
> > My simple test was ``make buildkernel'' while watching the core usage with
> > gkrellm.
> >
> > With SCHED_4BSD all 6 cores are loaded to 97% during the build phase.
> > I've never seen any value above 97% with gkrellm.
> >
> > With SCHED_ULE I never saw all 6 cores loaded this heavily.  Usually
> > 2 or more cores were at or below 90%.  Not really that significant, but
> > still a noticeable difference in apparent scheduling behavior.  Whether
> > the observed difference is due to some change in data from the kernel to
> > gkrellm is beyond me.
>
> SCHED_ULE is much sloppier about calculating which thread used a
> timeslice -- unless the timeslice went 100% to a thread, the fraction
> it used may get attributed elsewhere.  So top's reporting of thread
> usage is not a useful metric.  Total buildworld time is, potentially.
>

I suspect you're right since the buildworld time, a much better test,
was pretty much the same with 4BSD and ULE.

--
Gary Jennejohn
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

Steve Kargl
In reply to this post by Bruce Cran
On Mon, Dec 12, 2011 at 04:18:35PM +0000, Bruce Cran wrote:

> On 12/12/2011 15:51, Steve Kargl wrote:
> >This comes up every 9 months or so, and must be approaching FAQ
> >status. In a HPC environment, I recommend 4BSD. Depending on the
> >workload, ULE can cause a severe increase in turn around time when
> >doing already long computations. If you have an MPI application,
> >simply launching greater than ncpu+1 jobs can show the problem. PS:
> >search the list archives for "kargl and ULE".
>
> This isn't something that can be fixed by tuning ULE? For example for
> desktop applications kern.sched.preempt_thresh should be set to 224 from
> its default. I'm wondering if the installer should ask people what the
> typical use will be, and tune the scheduler appropriately.
>

Tuning kern.sched.preempt_thresh did not seem to help for
my workload.  My code is a classic master-slave OpenMPI
application where the master runs on one node and all
cpu-bound slaves are sent to a second node.  If I send
send ncpu+1 jobs to the 2nd node with ncpu's, then
ncpu-1 jobs are assigned to the 1st ncpu-1 cpus.  The
last two jobs are assigned to the ncpu'th cpu, and
these ping-pong on the this cpu.  AFAICT, it is a cpu
affinity issue, where ULE is trying to keep each job
associated with its initially assigned cpu.

While one might suggest that starting ncpu+1 jobs
is not prudent, my example is just that.  It is an
example showing that ULE has performance issues.
So, I now can start only ncpu jobs on each node
in the cluster and send emails to all other users
to not use those node, or use 4BSD and not worry
about loading issues.

--
Steve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

John Baldwin
On Monday, December 12, 2011 12:06:04 pm Steve Kargl wrote:

> On Mon, Dec 12, 2011 at 04:18:35PM +0000, Bruce Cran wrote:
> > On 12/12/2011 15:51, Steve Kargl wrote:
> > >This comes up every 9 months or so, and must be approaching FAQ
> > >status. In a HPC environment, I recommend 4BSD. Depending on the
> > >workload, ULE can cause a severe increase in turn around time when
> > >doing already long computations. If you have an MPI application,
> > >simply launching greater than ncpu+1 jobs can show the problem. PS:
> > >search the list archives for "kargl and ULE".
> >
> > This isn't something that can be fixed by tuning ULE? For example for
> > desktop applications kern.sched.preempt_thresh should be set to 224 from
> > its default. I'm wondering if the installer should ask people what the
> > typical use will be, and tune the scheduler appropriately.
> >
>
> Tuning kern.sched.preempt_thresh did not seem to help for
> my workload.  My code is a classic master-slave OpenMPI
> application where the master runs on one node and all
> cpu-bound slaves are sent to a second node.  If I send
> send ncpu+1 jobs to the 2nd node with ncpu's, then
> ncpu-1 jobs are assigned to the 1st ncpu-1 cpus.  The
> last two jobs are assigned to the ncpu'th cpu, and
> these ping-pong on the this cpu.  AFAICT, it is a cpu
> affinity issue, where ULE is trying to keep each job
> associated with its initially assigned cpu.
>
> While one might suggest that starting ncpu+1 jobs
> is not prudent, my example is just that.  It is an
> example showing that ULE has performance issues.
> So, I now can start only ncpu jobs on each node
> in the cluster and send emails to all other users
> to not use those node, or use 4BSD and not worry
> about loading issues.

This is a case where 4BSD's naive algorithm will spread out the load more
evenly because all the threads are on a single, shared queue and each CPU
just grabs the head of the queue when it finishes a timeslice.  ULE always
assigns threads to a single CPU (even if they aren't pinned to a single
CPU using cpuset, etc.) and then tries to balance the load across cores
later, but I believe in this case it's rebalancer won't have anything to
really do as no matter what it does with the N+1 job it's going to be
sharing a CPU with another job.

--
John Baldwin
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

Scott Lambert
In reply to this post by Steve Kargl
On Mon, Dec 12, 2011 at 09:06:04AM -0800, Steve Kargl wrote:

> Tuning kern.sched.preempt_thresh did not seem to help for
> my workload.  My code is a classic master-slave OpenMPI
> application where the master runs on one node and all
> cpu-bound slaves are sent to a second node.  If I send
> send ncpu+1 jobs to the 2nd node with ncpu's, then
> ncpu-1 jobs are assigned to the 1st ncpu-1 cpus.  The
> last two jobs are assigned to the ncpu'th cpu, and
> these ping-pong on the this cpu.  AFAICT, it is a cpu
> affinity issue, where ULE is trying to keep each job
> associated with its initially assigned cpu.
>
> While one might suggest that starting ncpu+1 jobs
> is not prudent, my example is just that.  It is an
> example showing that ULE has performance issues.
> So, I now can start only ncpu jobs on each node
> in the cluster and send emails to all other users
> to not use those node, or use 4BSD and not worry
> about loading issues.

Does it meet your expectations if you start (j modulo ncpu) = 0
jobs on a node?

--
Scott Lambert                    KC5MLE                       Unix SysAdmin
[hidden email]

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

Steve Kargl
On Mon, Dec 12, 2011 at 01:03:30PM -0600, Scott Lambert wrote:

> On Mon, Dec 12, 2011 at 09:06:04AM -0800, Steve Kargl wrote:
> > Tuning kern.sched.preempt_thresh did not seem to help for
> > my workload.  My code is a classic master-slave OpenMPI
> > application where the master runs on one node and all
> > cpu-bound slaves are sent to a second node.  If I send
> > send ncpu+1 jobs to the 2nd node with ncpu's, then
> > ncpu-1 jobs are assigned to the 1st ncpu-1 cpus.  The
> > last two jobs are assigned to the ncpu'th cpu, and
> > these ping-pong on the this cpu.  AFAICT, it is a cpu
> > affinity issue, where ULE is trying to keep each job
> > associated with its initially assigned cpu.
> >
> > While one might suggest that starting ncpu+1 jobs
> > is not prudent, my example is just that.  It is an
> > example showing that ULE has performance issues.
> > So, I now can start only ncpu jobs on each node
> > in the cluster and send emails to all other users
> > to not use those node, or use 4BSD and not worry
> > about loading issues.
>
> Does it meet your expectations if you start (j modulo ncpu) = 0
> jobs on a node?
>

I've never tried to launch more than ncpu + 1 (or + 2)
jobs.  I suppose at the time I was investigating the issue,
it was determined that 4BSD allowed me to get my work done
in a more timely manner.  So, I took the path of least
resistance.

--
Steve
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

O. Hartmann-4
In reply to this post by Steve Kargl
On 12/12/11 18:06, Steve Kargl wrote:

> On Mon, Dec 12, 2011 at 04:18:35PM +0000, Bruce Cran wrote:
>> On 12/12/2011 15:51, Steve Kargl wrote:
>>> This comes up every 9 months or so, and must be approaching FAQ
>>> status. In a HPC environment, I recommend 4BSD. Depending on the
>>> workload, ULE can cause a severe increase in turn around time when
>>> doing already long computations. If you have an MPI application,
>>> simply launching greater than ncpu+1 jobs can show the problem. PS:
>>> search the list archives for "kargl and ULE".
>>
>> This isn't something that can be fixed by tuning ULE? For example for
>> desktop applications kern.sched.preempt_thresh should be set to 224 from
>> its default. I'm wondering if the installer should ask people what the
>> typical use will be, and tune the scheduler appropriately.
>>
Is the tuning of kern.sched.preempt_thresh and a proper method of
estimating its correct value for the intended to use workload documented
in the manpages, maybe tuning()?

I find it hard to crawl a lot of pros and cons of mailing lists for
evaluating a correct value of this, seemingly, important tunable.

>
> Tuning kern.sched.preempt_thresh did not seem to help for
> my workload.  My code is a classic master-slave OpenMPI
> application where the master runs on one node and all
> cpu-bound slaves are sent to a second node.  If I send
> send ncpu+1 jobs to the 2nd node with ncpu's, then
> ncpu-1 jobs are assigned to the 1st ncpu-1 cpus.  The
> last two jobs are assigned to the ncpu'th cpu, and
> these ping-pong on the this cpu.  AFAICT, it is a cpu
> affinity issue, where ULE is trying to keep each job
> associated with its initially assigned cpu.
>
> While one might suggest that starting ncpu+1 jobs
> is not prudent, my example is just that.  It is an
> example showing that ULE has performance issues.
> So, I now can start only ncpu jobs on each node
> in the cluster and send emails to all other users
> to not use those node, or use 4BSD and not worry
> about loading issues.
>


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

Bruce Cran
On 12/12/2011 23:48, O. Hartmann wrote:
> Is the tuning of kern.sched.preempt_thresh and a proper method of
> estimating its correct value for the intended to use workload
> documented in the manpages, maybe tuning()? I find it hard to crawl a
> lot of pros and cons of mailing lists for evaluating a correct value
> of this, seemingly, important tunable.

Note that I said "for example" :)
I was suggesting that there may be sysctl's that can be tweaked to
improve performance.

--
Bruce Cran
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

dougb
In reply to this post by Hartmann, O.
On 12/12/2011 05:47, O. Hartmann wrote:
> Do we have any proof at hand for such cases where SCHED_ULE performs
> much better than SCHED_4BSD?

I complained about poor interactive performance of ULE in a desktop
environment for years. I had numerous people try to help, including
Jeff, with various tunables, dtrace'ing, etc. The cause of the problem
was never found.

I switched to 4BSD, problem gone.

This is on 2 separate systems with core 2 duos.


hth,

Doug

--

                [^L]

        Breadth of IT experience, and depth of knowledge in the DNS.
        Yours for the right price.  :)  http://SupersetSolutions.com/

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: SCHED_ULE should not be the default

Jeremy Chadwick
In reply to this post by Hartmann, O.
On Mon, Dec 12, 2011 at 02:47:57PM +0100, O. Hartmann wrote:

> > Not fully right, boinc defaults to run on idprio 31 so this isn't an
> > issue. And yes, there are cases where SCHED_ULE shows much better
> > performance then SCHED_4BSD.  [...]
>
> Do we have any proof at hand for such cases where SCHED_ULE performs
> much better than SCHED_4BSD? Whenever the subject comes up, it is
> mentioned, that SCHED_ULE has better performance on boxes with a ncpu >
> 2. But in the end I see here contradictionary statements. People
> complain about poor performance (especially in scientific environments),
> and other give contra not being the case.
>
> Within our department, we developed a highly scalable code for planetary
> science purposes on imagery. It utilizes present GPUs via OpenCL if
> present. Otherwise it grabs as many cores as it can.
> By the end of this year I'll get a new desktop box based on Intels new
> Sandy Bridge-E architecture with plenty of memory. If the colleague who
> developed the code is willing performing some benchmarks on the same
> hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most
> recent Suse. For FreeBSD I intent also to look for performance with both
> different schedulers available.

This is in no way shape or form the same kind of benchmark as what
you're planning to do, but I thought I'd throw it out there for folks to
take in as they see fit.

I know folks were focused mainly on buildworld.

I personally would find it interesting if someone with a higher-end
system (e.g. 2 physical CPUs, with 6 or 8 cores per CPU) was to do the
same test (changing -jX to -j{numofcores} of course).

--
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                   Mountain View, CA, US |
| Making life hard for others since 1977.               PGP 4BD6C0CB |


sched_ule
===========
- time make -j2 buildworld
  1689.831u 229.328s 18:46.20 170.4% 6566+2051k 432+4264io 4565pf+0w
- time make -j2 buildkernel
  640.542u 87.737s 9:01.38 134.5% 6490+1920k 134+5968io 0pf+0w


sched_4bsd
============
- time make -j2 buildworld
  1662.793u 206.908s 17:12.02 181.1% 6578+2054k 23750+4271io 6451pf+0w
- time make -j2 buildkernel
  638.717u 76.146s 8:34.90 138.8% 6530+1927k 6415+5903io 0pf+0w


software
==========
* sched_ule test:  FreeBSD 8.2-STABLE, Thu Dec  1 04:37:29 PST 2011
* sched_4bsd test: FreeBSD 8.2-STABLE, Mon Dec 12 22:42:54 PST 2011


hardware
==========
* Intel Core 2 Duo E8400, 3GHz
* Supermicro X7SBA
* 8GB ECC RAM (4x2GB), DDR2-800
* Intel 320-series SSD, 80GB: /, swap, /var, /tmp, /usr


tuning adjustments / etc.
===========================
* Before each scheduler test, system was rebooted to ensure I/O cache
  and other whatnots were empty
* All filesystems stock UFS2 + SU (root is non-SU)
* All filesystems had tunefs -t enable applied to them
* powerd(8) in use, with two rc.conf variables (per CPU spec):

performance_cx_lowest="C2"
economy_cx_lowest="C2"

* loader.conf

kern.maxdsiz="2560M"
kern.dfldsiz="2560M"
kern.maxssiz="256M"
ahci_load="yes"
hint.p4tcc.0.disabled="1"
hint.acpi_throttle.0.disabled="1"
vfs.zfs.arc_max="5120M"

* make.conf

CPUTYPE?=core2

* src.conf

WITHOUT_INET6=true
WITHOUT_IPFILTER=true
WITHOUT_LIB32=true
WITHOUT_KERBEROS=true
WITHOUT_PAM_SUPPORT=true
WITHOUT_PROFILE=true
WITHOUT_SENDMAIL=true

* kernel configuration
  - note: between kernel builds, config was changed to either use
    SCHED_4BSD or SCHED_ULE respectively.

cpu             HAMMER
ident           GENERIC

makeoptions     DEBUG=-g                # Build kernel with gdb(1) debug symbols

options         SCHED_4BSD              # Classic BSD scheduler
#options        SCHED_ULE               # ULE scheduler
options         PREEMPTION              # Enable kernel thread preemption
options         INET                    # InterNETworking
options         FFS                     # Berkeley Fast Filesystem
options         SOFTUPDATES             # Enable FFS soft updates support
options         UFS_ACL                 # Support for access control lists
options         UFS_DIRHASH             # Improve performance on big directories
options         UFS_GJOURNAL            # Enable gjournal-based UFS journaling
options         MD_ROOT                 # MD is a potential root device
options         NFSCLIENT               # Network Filesystem Client
options         NFSSERVER               # Network Filesystem Server
options         NFSLOCKD                # Network Lock Manager
options         NFS_ROOT                # NFS usable as /, requires NFSCLIENT
options         MSDOSFS                 # MSDOS Filesystem
options         CD9660                  # ISO 9660 Filesystem
options         PROCFS                  # Process filesystem (requires PSEUDOFS)
options         PSEUDOFS                # Pseudo-filesystem framework
options         GEOM_PART_GPT           # GUID Partition Tables.
options         GEOM_LABEL              # Provides labelization
options         COMPAT_43TTY            # BSD 4.3 TTY compat (sgtty)
options         SCSI_DELAY=5000         # Delay (in ms) before probing SCSI
options         KTRACE                  # ktrace(1) support
options         STACK                   # stack(9) support
options         SYSVSHM                 # SYSV-style shared memory
options         SYSVMSG                 # SYSV-style message queues
options         SYSVSEM                 # SYSV-style semaphores
options         P1003_1B_SEMAPHORES     # POSIX-style semaphores
options         _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions
options         PRINTF_BUFR_SIZE=128    # Prevent printf output being interspersed.
options         KBD_INSTALL_CDEV        # install a CDEV entry in /dev
options         HWPMC_HOOKS             # Necessary kernel hooks for hwpmc(4)
options         AUDIT                   # Security event auditing
options         MAC                     # TrustedBSD MAC Framework
options         FLOWTABLE               # per-cpu routing cache
#options        KDTRACE_FRAME           # Ensure frames are compiled in
#options        KDTRACE_HOOKS           # Kernel DTrace hooks
options         INCLUDE_CONFIG_FILE     # Include this file in kernel

# Make an SMP-capable kernel by default
options         SMP                     # Symmetric MultiProcessor Kernel

# Debugging options
options         BREAK_TO_DEBUGGER       # Sending a serial BREAK drops to DDB
options         ALT_BREAK_TO_DEBUGGER   # Permit <CR>~<Ctrl-b> to drop to DDB
options         KDB                     # Enable kernel debugger support
options         KDB_TRACE               # Print stack trace automatically on panic
options         DDB                     # Support DDB
options         DDB_NUMSYM              # Print numeric value of symbols
options         GDB                     # Support remote GDB

# CPU frequency control
device          cpufreq

# Bus support.
device          acpi
device          pci

# Floppy drives
device          fdc

# ATA and ATAPI devices
# NOTE: "device ata" is missing because we use the Modular ATA core
# to only include the ATA-related drivers we need (e.g. AHCI).
device          atadisk         # ATA disk drives
device          ataraid         # ATA RAID drives
device          atapicd         # ATAPI CDROM drives
options         ATA_STATIC_ID   # Static device numbering

# Modular ATA
device          atacore         # Core ATA functionality
device          ataisa          # ISA bus support
device          atapci          # PCI bus support; only generic chipset support
device          ataahci         # AHCI SATA
device          ataintel        # Intel

# SCSI peripherals
device          scbus           # SCSI bus (required for SCSI)
device          da              # Direct Access (disks)
device          cd              # CD
device          pass            # Passthrough device (direct SCSI access)
device          ses             # SCSI Environmental Services (and SAF-TE)
options         CAMDEBUG        # CAM debugging (camcontrol debug)

# atkbdc0 controls both the keyboard and the PS/2 mouse
device          atkbdc          # AT keyboard controller
device          atkbd           # AT keyboard
device          psm             # PS/2 mouse

device          kbdmux          # keyboard multiplexer

device          vga             # VGA video card driver

device          splash          # Splash screen and screen saver support

# syscons is the default console driver, resembling an SCO console
device          sc

device          agp             # support several AGP chipsets

# Serial (COM) ports
device          uart            # Generic UART driver

# PCI Ethernet NICs.
device          em              # Intel PRO/1000 Gigabit Ethernet Family

# Wireless NIC cards
device          wlan            # 802.11 support
options         IEEE80211_DEBUG # enable debug msgs
options         IEEE80211_AMPDU_AGE     # age frames in AMPDU reorder q's
device          wlan_wep        # 802.11 WEP support
device          wlan_ccmp       # 802.11 CCMP support
device          wlan_tkip       # 802.11 TKIP support
device          wlan_amrr       # AMRR transmit rate control algorithm
device          wlan_acl        # MAC Access Control List support

# Pseudo devices.
device          loop            # Network loopback
device          random          # Entropy device
device          ether           # Ethernet support
device          pty             # BSD-style compatibility pseudo ttys
device          md              # Memory "disks"
device          gif             # IPv6 and IPv4 tunneling
device          faith           # IPv6-to-IPv4 relaying (translation)
device          firmware        # firmware assist module

# The `bpf' device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling this!
# Note that 'bpf' is required for DHCP.
device          bpf             # Berkeley packet filter

# USB support
device          uhci            # UHCI PCI->USB interface
device          ohci            # OHCI PCI->USB interface
device          ehci            # EHCI PCI->USB interface (USB 2.0)
device          usb             # USB Bus (required)
#device         udbp            # USB Double Bulk Pipe devices
device          uhid            # "Human Interface Devices"
device          ukbd            # Keyboard
device          umass           # Disks/Mass storage - Requires scbus and da
device          ums             # Mouse

# Intel Core/Core2Duo CPU temperature monitoring driver
device          coretemp

# SMBus support, needed for bsdhwmon
device          smbus
device          smb
device          ichsmb

# Intel ICH hardware watchdog support
device          ichwd

# pf ALTQ support
options         ALTQ
options         ALTQ_CBQ        # Class Bases Queueing
options         ALTQ_RED        # Random Early Detection
options         ALTQ_RIO        # RED In/Out
options         ALTQ_HFSC       # Hierarchical Packet Scheduler
options         ALTQ_CDNR       # Traffic conditioner
options         ALTQ_PRIQ       # Priority Queueing
options         ALTQ_NOPCC      # Required for SMP build

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[hidden email]"
1234