Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

PREEMPT_RT vs ADEOS: the numbers, part 1

64 views
Skip to first unread message

Kristian Benoit

unread,
Jun 11, 2005, 12:50:06 AM6/11/05
to
For the past few weeks, we've been conducting comparison tests between
PREEMPT_RT and the Adeos nanokernel. As was clear from previous discussion,
we've been open to be proven wrong regarding endorsement of either method.
Hence, this comparison was done in order to better understand the impact
of each method vis-a-vis vanilla Linux.

At this time, we are publishing the summary results of the various test
runs we've conducted. There is, of course, a lot of background information
that needs to be provided (.configs, scripts, drivers, etc.) We will be
making those available sometime early next week. In the mean time, the
following is meant as food-for-thought.

In our tests, we've used a set up with 3 machines. The two main systems
were Dell PowerEdge SC420 machines with a P4 2.8 (UP not SMP configured) with
FC3. One had 256 MB RAM and was the guinea pig (i.e. the machine controlling
the mechanical saw a.k.a. TARGET) The other, having 512 MB RAM, was used to
collect data regarding the guinea pig's responsiveness (a.k.a LOGGER.) The
third machine, an Apple PowerBook 5,6 G4 / 1GB, was used for a dual purpose.
First, it controlled both the target and the logger via ssh, and was also
used to ping flood the target. This 3rd system is known as the HOST.

Data was generated on all three systems:
TARGET: LMbench data
LOGGER: Interrupt response time
HOST: LMbench total running time

Both the host and the logger had a constant kernel configuration. The logger
was running an adeos-enabled kernel in order to trigger and deterministically
measure the responsiveness of the target. The host was running a plain
gentoo-based kernel. The target and the logger were rigged via their parallel
ports so that an output from the logger would trigger an interrupt on the
target who's response would itself trigger an interrupt on the logger.

In the various test runs, we've attempted to collect two sets of data. One
regarding LMbench's total running time for a given set up and the other
regarding the system's interrupt response time. Where appropriate, both tests
were conducted simultaneously. Otherwise, they were conducted in isolation.
The following tables should be self-explanatory.

For LMbench test runs, 3 passes were conducted and an average running time
was collected. Certainly, 3 passes is not as much as we'd like, but for the
immediate purposes, it provides a sufficiently corroborated data set for
analysis (as can be seen in the following tables.)

For the interrupt response time measurement, the logger generated between
500,000 to 650,000 interrupts and measured the target's response time. The
logger was not subject to any load whatsoever, except that imposed by the
logging driver (running in a prioritary Adeos domain, and hence being truly
hard-rt, a.k.a. "ruby" hard) and that of the user-space daemon committing the
data to storage. It could be argued that the use of Adeos imposes a penalty
to the measured response time. However, this penalty is imposed on all data
sets, and verification of its impact can be inferred by analyzing the adeos-to-
adeos set up provided below.

With no further ado, here are the results we've obtained. As we said above, we
will be making all related scripts, patches, and drivers available, so that
others may conduct their own tests.

Note that in the tests we've conducted, we've tried, in as much possible, to
use similar kernels. However, we were unable to find a recent Adeos and a
recent PREEMPT_RT patch which would both cleanly apply to a same recent kernel.
Hence, we've compared vanilla 2.6.12-rc2 with an adeos-patched one and a
2.6.12-rc4 with a PREEMPT_RT-patched one. As can be seen below, the runs of
the vanilla rc2 and rc4 yield very similar numbers, and can therefore
reasonably be considered equivalent.

LMbench running times:
+--------------------+--------+----------+------------+------------+----------+
| Kernel | plain | IRQ test | ping flood | IRQ & ping | IRQ & hd |
+====================+========+==========+============+============+==========+
| Vanilla-2.6.12-rc2 | 174 s | 175 s | 189 s | 193 s | 217 s |
+--------------------+--------+----------+------------+------------+----------+
| with Adeos-r10c3 | 180 s | 180 s | 185 s | 183 s | 211 s |
+--------------------+--------+----------+------------+------------+----------+
| % | +3.4 | +2.9 | -2.1 | -5.2 | -2.8 |
+====================+========+==========+============+============+==========+
| Vanilla-2.6.12-rc4 | 176 s | 177 s | 189 s | 191 s | 218 s |
+--------------------+--------+----------+------------+------------+----------+
| with RT-V0.7.47-08 | 184 s | 187 s | 206 s | 201 s | 225 s |
+--------------------+--------+----------+------------+------------+----------+
| % | +4.5 | +5.6 | +9.0 | +5.2 | +3.2 |
+--------------------+--------+----------+------------+------------+----------+

Legend:
plain = Nothing special
IRQ test = on logger: triggering target every 1ms
ping flood = on host: "sudo ping -f $TARGET_IP_ADDR"
IRQ & ping = combination of the previous two
IRQ & hd = IRQ test with the following being done on the target:
"while [ true ]
do dd if=/dev/zero of=/tmp/dummy count=512
done"

In the following, interrupts are triggered by the logger at every 1ms. It would
be interesting to redo such tests with shorter trigger times. However, we
wanted to keep the logger as "off-the-shelf" as possible.

Interrupt response times (all in micro-seconds):
+--------------------+------------+------+-------+------+--------+
| Kernel | sys load | Aver | Max | Min | StdDev |
+====================+============+======+=======+======+========+
| | None | 15.5 | 64.8 | 15.2 | 1.0 |
| | Ping | 15.7 | 63.4 | 15.2 | 1.2 |
| Vanilla-2.6.12-rc2 | lm. + ping | 16.0 | 72.2 | 15.2 | 1.4 |
| | lmbench | 15.8 | 65.6 | 15.2 | 1.1 |
| | lm. + hd | 15.8 | 179.9 | 15.2 | 1.3 |
+--------------------+------------+------+-------+------+--------+
| | None | 13.4 | 53.3 | 13.2 | 0.2 |
| | Ping | 13.8 | 53.3 | 13.3 | 0.6 |
| with Adeos-r10c3 | lm.+ ping | 13.9 | 21.8 | 13.2 | 0.7 |
| | lmbench | 13.9 | 21.3 | 13.3 | 0.6 |
| | lm. + hd | 13.9 | 53.2 | 13.2 | 0.5 |
+====================+============+======+=======+======+========+
| | None | 15.2 | 64.2 | 15.2 | 0.5 |
| | Ping | 15.6 | 63.0 | 15.2 | 0.9 |
| Vanilla-2.6.12-rc4 | lm. + ping | 16.0 | 170.5 | 16.0 | 1.4 |
| | lmbench | 15.8 | 184.1 | 15.2 | 1.2 |
| | lm. + hd | 15.8 | 67.1 | 15.0 | 1.1 |
+--------------------+------------+------+-------+------+--------+
| | None | 15.5 | 73.8 | 15.2 | 1.2 |
| | Ping | 17.1 | 79.8 | 15.2 | 2.3 |
| with RT-V0.7.47-08 | lm. + ping | 17.7 | 77.2 | 15.2 | 3.1 |
| | lmbench | 17.1 | 80.0 | 15.3 | 2.3 |
| | lm. + hd | 17.0 | 80.0 | 15.3 | 1.8 |
+--------------------+------------+------+-------+------+--------+

Legend:
None = nothing special
ping = on host: "sudo ping -f $TARGET_IP_ADDR"
lm. + ping = previous test and "make rerun" in lmbench-2.0.4/src/ on target
lmbench = "make rerun" in lmbench-2.0.4/src/ on target
lm. + hd = previous test with the following being done on the target:
"while [ true ]
do dd if=/dev/zero of=/tmp/dummy count=512
done"

Note: Adeos-r10c3 is a "combo" patch including both Adeos and PREEMPT_RT, though
PREEMPT_RT is disabled.

The above data has been provided as-is without any analysis for now. We will
provide such analysis when publishing the complete data sets and related
software. In the mean time, we hope such results will help further reflection.

Best regards and have fun !!!

Kristian Benoit
Karim Yaghmour
--
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || 1-866-677-4546


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Nick Piggin

unread,
Jun 11, 2005, 2:20:08 AM6/11/05
to
Kristian Benoit wrote:
> For the past few weeks, we've been conducting comparison tests between
> PREEMPT_RT and the Adeos nanokernel. As was clear from previous discussion,
> we've been open to be proven wrong regarding endorsement of either method.
> Hence, this comparison was done in order to better understand the impact
> of each method vis-a-vis vanilla Linux.
>

This is wonderful data, thanks very much for putting in the work.
I hope this thread and future threads on this topic can be steered
more towards technical facts and numbers, as that is the only way
to make sane choices.

Nick

--
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com

Ingo Molnar

unread,
Jun 11, 2005, 3:20:06 AM6/11/05
to

could you send me the .config you used for the PREEMPT_RT tests? Also,
you used -47-08, which was well prior the current round of performance
improvements, so you might want to re-run with something like -48-06 or
better.

Ingo

Nick Piggin

unread,
Jun 11, 2005, 3:50:07 AM6/11/05
to
Ingo Molnar wrote:
> could you send me the .config you used for the PREEMPT_RT tests? Also,
> you used -47-08, which was well prior the current round of performance
> improvements, so you might want to re-run with something like -48-06 or
> better.
>

The other thing that would be really interesting is to test latencies
of various other kernel functionalities in the RT kernel (eg. message
passing, maybe pipe or localhost read/write, signals, fork/clone/exit,
mmap/munmap, faulting in shared memory, or whatever else is important
to the RT crowd).

--
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com

Sven-Thorsten Dietrich

unread,
Jun 11, 2005, 5:20:07 AM6/11/05
to
On Sat, 2005-06-11 at 16:14 +1000, Nick Piggin wrote:
> Kristian Benoit wrote:
> > For the past few weeks, we've been conducting comparison tests between
> > PREEMPT_RT and the Adeos nanokernel. As was clear from previous discussion,
> > we've been open to be proven wrong regarding endorsement of either method.
> > Hence, this comparison was done in order to better understand the impact
> > of each method vis-a-vis vanilla Linux.
> >
>
> This is wonderful data, thanks very much for putting in the work.
> I hope this thread and future threads on this topic can be steered
> more towards technical facts and numbers, as that is the only way
> to make sane choices.
>

Its a good start, and its excellent that its being looked at. Thank you
guys very much for taking the time to compare these 2 very different
systems.

I am too looking forward to seeing results against the >= 07.48 RT
kernels incorporating Daniel's recent IRQ disable relief.

I think the comparison should absolutely compare identical community
kernels. The comparison between two different release candidates is
questionable. rc2 to rc4 doesn't seem like much, after all, how much
code could go into a release candidate. (diff | wc -l)

Also, I question testing -rc code in the first place, except for
regression purposes.

Linus, Andrew, and everyone else apply due diligence to drop stable
kernels along the way :) (Thanks very much).

The -rc code in between is impressive, but not always as stable, or as
high quality, for obvious reasons. It is integration work in progress.

Finally, there are other big-picture issues. How hard is it to maintain
the code in general? At the risk of ruffling feathers, forward-porting
RT code (or backporting) it a few revisions of rc's isn't too bad.

At Ingo's pace, we have all done some of that.

How does that effort compare for porting ADEOS code? If several weeks of
work are invested in a comparison of rc2 to rc4, how much additional
work is needed to bring Adeos up to the base for the current RT kernel?

In addition, I think the discrepancy between the vanilla kernel and the
RT kernel could be much greater, if the workload specifically, or even
coincidentally exercised bottlenecks.

I'll stop there, at the brink of speculating, and await the scripts and
background info.

Cheers,

Sven

Sven-Thorsten Dietrich

unread,
Jun 11, 2005, 5:40:09 AM6/11/05
to
On Sat, 2005-06-11 at 17:44 +1000, Nick Piggin wrote:
> Ingo Molnar wrote:
> > could you send me the .config you used for the PREEMPT_RT tests? Also,
> > you used -47-08, which was well prior the current round of performance
> > improvements, so you might want to re-run with something like -48-06 or
> > better.
> >
>
> The other thing that would be really interesting is to test latencies
> of various other kernel functionalities in the RT kernel (eg. message
> passing, maybe pipe or localhost read/write, signals, fork/clone/exit,
> mmap/munmap, faulting in shared memory, or whatever else is important
> to the RT crowd).
>

I have recently seen an analysis of this. It was internal to a customer,
but I will ask whether they object to publishing it.

Notably, there are naturally discrepancies between user space and kernel
tasks. An example of this is thread-spawn benchmarks. That is relevant
to folks who have RT code with IP to protect that must run in user
space.

Sven

Ingo Molnar

unread,
Jun 11, 2005, 6:50:12 AM6/11/05
to

* Ingo Molnar <mi...@elte.hu> wrote:

> could you send me the .config you used for the PREEMPT_RT tests? Also,
> you used -47-08, which was well prior the current round of performance
> improvements, so you might want to re-run with something like -48-06
> or better.

make that -48-10 or better.

Kristian Benoit

unread,
Jun 11, 2005, 10:10:13 AM6/11/05
to
On Sat, 2005-06-11 at 16:14 +1000, Nick Piggin wrote:
> This is wonderful data, thanks very much for putting in the work.
> I hope this thread and future threads on this topic can be steered
> more towards technical facts and numbers, as that is the only way
> to make sane choices.

Glad you like it.

Kristian Benoit

unread,
Jun 11, 2005, 10:20:07 AM6/11/05
to
On Sat, 2005-06-11 at 02:15 -0700, Sven-Thorsten Dietrich wrote:
> Its a good start, and its excellent that its being looked at. Thank
> you
> guys very much for taking the time to compare these 2 very different
> systems.

Youre welcome !

> I think the comparison should absolutely compare identical community
> kernels. The comparison between two different release candidates is
> questionable. rc2 to rc4 doesn't seem like much, after all, how much
> code could go into a release candidate. (diff | wc -l)

I agree with that, but as the results show, there does'nt seems to be
much difference impact the numbers in the tested field.

> Also, I question testing -rc code in the first place, except for
> regression purposes.

I tested the -rc code in orther to be able to compare the patched
kernels against theird own source.

> How does that effort compare for porting ADEOS code? If several weeks
> of
> work are invested in a comparison of rc2 to rc4, how much additional
> work is needed to bring Adeos up to the base for the current RT
> kernel?

Philippe, I think that question is youre !

Kristian

Zwane Mwaikambo

unread,
Jun 11, 2005, 10:30:13 AM6/11/05
to
On Sat, 11 Jun 2005, Nick Piggin wrote:

> Kristian Benoit wrote:
> > For the past few weeks, we've been conducting comparison tests between
> > PREEMPT_RT and the Adeos nanokernel. As was clear from previous discussion,
> > we've been open to be proven wrong regarding endorsement of either method.
> > Hence, this comparison was done in order to better understand the impact
> > of each method vis-a-vis vanilla Linux.
> >
>
> This is wonderful data, thanks very much for putting in the work.
> I hope this thread and future threads on this topic can be steered
> more towards technical facts and numbers, as that is the only way
> to make sane choices.

I think it'd also be interesting to see results with a heavy scheduling
load (say make -jN). Not only would this clobber caches, it'd also show
possible issues regarding contention or long preemption disabled points.

Zwane

Kristian Benoit

unread,
Jun 11, 2005, 10:30:12 AM6/11/05
to
On Sat, 2005-06-11 at 12:37 +0200, Ingo Molnar wrote:
>
> > could you send me the .config you used for the PREEMPT_RT tests?
> Also,
> > you used -47-08, which was well prior the current round of
> performance
> > improvements, so you might want to re-run with something like
> -48-06
> > or better.
>
> make that -48-10 or better.

I get on that monday morning.

> one has to make sure the default debug options are disabled.
> (DEADLOCK_DETECT, PREEMPT_DEBUG, etc.)

Can you tell me the exact list of option where talking about ?

Kristian

Kristian Benoit

unread,
Jun 11, 2005, 10:40:07 AM6/11/05
to
On Sat, 2005-06-11 at 17:44 +1000, Nick Piggin wrote:
> Ingo Molnar wrote:
> > could you send me the .config you used for the PREEMPT_RT tests? Also,
> > you used -47-08, which was well prior the current round of performance
> > improvements, so you might want to re-run with something like -48-06 or
> > better.
> >
>
> The other thing that would be really interesting is to test latencies
> of various other kernel functionalities in the RT kernel (eg. message
> passing, maybe pipe or localhost read/write, signals, fork/clone/exit,
> mmap/munmap, faulting in shared memory, or whatever else is important
> to the RT crowd).

It is'nt be really hard to had different tests to the actual test set.
You'll be able to make your own tests soon.

Karim Yaghmour

unread,
Jun 11, 2005, 10:50:08 AM6/11/05
to

Ingo Molnar wrote:
> could you send me the .config you used for the PREEMPT_RT tests? Also,
> you used -47-08, which was well prior the current round of performance
> improvements, so you might want to re-run with something like -48-06 or
> better.

Much to our dislike, we only noticed that we forgot to disable the debug
options after posting the results :/ So, in all fairness, we will be
redoing the tests on PREEMPT_RT early next week. In the plethora of things
we wanted to try, it also seems that the "dd" test wasn't exactly as it
was supposed to be. There should've been a "bs=1M" in there; as it
currently is, the dd command doesn't really put any real load. We'll add
this one to our repeats.

I notice there are already suggestions regarding additional types of
tests, and that's good. We'll try to take as many of these as possible.
This is relatively simple given the scripts Kristian has put together.
Nevertheless, it must be understood that we don't have infinite resources.
So in sharing the framework we've developed, we hope others will be
motivated to conduct their own tests.

Karim
--
Author, Speaker, Developer, Consultant


Pushing Embedded and Real-Time Linux Systems Beyond the Limits

http://www.opersys.com || ka...@opersys.com || 1-866-677-4546

Karim Yaghmour

unread,
Jun 11, 2005, 10:50:07 AM6/11/05
to

Sven-Thorsten Dietrich wrote:
> I am too looking forward to seeing results against the >= 07.48 RT
> kernels incorporating Daniel's recent IRQ disable relief.

Indeed, this is on our list.

> I think the comparison should absolutely compare identical community
> kernels. The comparison between two different release candidates is
> questionable. rc2 to rc4 doesn't seem like much, after all, how much
> code could go into a release candidate. (diff | wc -l)
>
> Also, I question testing -rc code in the first place, except for
> regression purposes.

On this issue, it has to be said that I don't think any set of test
results will suffice on its own as a definitive benchmark. There will
be a need for continued testing and publication of said results, which
we hope others will take part in when we publish the framework we've put
together.

> Finally, there are other big-picture issues. How hard is it to maintain
> the code in general? At the risk of ruffling feathers, forward-porting
> RT code (or backporting) it a few revisions of rc's isn't too bad.
>
> At Ingo's pace, we have all done some of that.
>
> How does that effort compare for porting ADEOS code? If several weeks of
> work are invested in a comparison of rc2 to rc4, how much additional
> work is needed to bring Adeos up to the base for the current RT kernel?

Philippe can correct me if I'm wrong, but adeos maintenance is not that
difficult. However, it has to be said that up until now, Philippe has been
the main driving force behind adeos. So while he's been fairly good at
publishing patches for as recent a kernel as possible, the manpower behind
PREEMPT_RT is obviously larger. That, though, only requires interested
parties to participate for it to change. Again, the adeos patch isn't
that big.

> In addition, I think the discrepancy between the vanilla kernel and the
> RT kernel could be much greater, if the workload specifically, or even
> coincidentally exercised bottlenecks.

If you've got any specific test run suggestions, we'll gladly take them.

Karim
--
Author, Speaker, Developer, Consultant

Pushing Embedded and Real-Time Linux Systems Beyond the Limits

http://www.opersys.com || ka...@opersys.com || 1-866-677-4546

Ingo Molnar

unread,
Jun 11, 2005, 11:00:20 AM6/11/05
to

* Karim Yaghmour <ka...@opersys.com> wrote:

> Ingo Molnar wrote:
> > could you send me the .config you used for the PREEMPT_RT tests? Also,
> > you used -47-08, which was well prior the current round of performance
> > improvements, so you might want to re-run with something like -48-06 or
> > better.
>
> Much to our dislike, we only noticed that we forgot to disable the
> debug options after posting the results :/ So, in all fairness, we

> will be redoing the tests on PREEMPT_RT early next week. [...]

yeah, i suspected something like that - the PREEMPT_RT latency numbers
were so out of whack with anything i've measured on similar boxes. The
debugging features on PREEMPT_RT are powerful but have a high overhead.

could you send me your PREEMPT_RT .config? (whichever version you have
handy) That's the easiest way i can tell you which options to watch out
for.

Ingo

Karim Yaghmour

unread,
Jun 11, 2005, 11:10:08 AM6/11/05
to

Ingo Molnar wrote:
> could you send me your PREEMPT_RT .config? (whichever version you have
> handy) That's the easiest way i can tell you which options to watch out
> for.

I'll see what I can do ... this being the weekend, it's a little bit more
trouble to get stuff off machines at the office ...

Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || ka...@opersys.com || 1-866-677-4546

Ingo Molnar

unread,
Jun 11, 2005, 11:10:04 AM6/11/05
to

* Kristian Benoit <kbe...@opersys.com> wrote:

> > one has to make sure the default debug options are disabled.
> > (DEADLOCK_DETECT, PREEMPT_DEBUG, etc.)
>
> Can you tell me the exact list of option where talking about ?

just send me a .config and i'll review it for PREEMPT_RT latency
performance. There can be many things depending on whether it's UP or
SMP, etc.

Ingo

Karim Yaghmour

unread,
Jun 11, 2005, 2:00:17 PM6/11/05
to

Ingo Molnar wrote:
> could you send me your PREEMPT_RT .config? (whichever version you have
> handy) That's the easiest way i can tell you which options to watch out
> for.

Here's the .config for 2.6.12-rc4-RT-V0.7.47-08:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.12-rc4-RT-V0.7.47-08
# Tue May 24 16:39:52 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_SMP is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT_DESKTOP is not set
CONFIG_PREEMPT_RT=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT_BKL=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ASM_SEMAPHORES=y
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
CONFIG_TOSHIBA=m
CONFIG_I8K=m
# CONFIG_X86_REBOOTFIXUPS is not set
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m

#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_NOHIGHMEM is not set
# CONFIG_HIGHMEM4G is not set
CONFIG_HIGHMEM64G=y
CONFIG_HIGHMEM=y
CONFIG_X86_PAE=y
CONFIG_HIGHPTE=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_HAVE_DEC_LOCK=y
CONFIG_REGPARM=y
CONFIG_SECCOMP=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_SOFTWARE_SUSPEND is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_ASUS=m
CONFIG_ACPI_IBM=m
CONFIG_ACPI_TOSHIBA=m
CONFIG_ACPI_BLACKLIST_YEAR=2001
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set

#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=y
# CONFIG_CPU_FREQ_STAT_DETAILS is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=m

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=m
CONFIG_X86_POWERNOW_K6=m
CONFIG_X86_POWERNOW_K7=y
CONFIG_X86_POWERNOW_K7_ACPI=y
CONFIG_X86_POWERNOW_K8=m
CONFIG_X86_POWERNOW_K8_ACPI=y
# CONFIG_X86_GX_SUSPMOD is not set
CONFIG_X86_SPEEDSTEP_CENTRINO=y
CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
CONFIG_X86_SPEEDSTEP_ICH=y
CONFIG_X86_SPEEDSTEP_SMI=m
CONFIG_X86_P4_CLOCKMOD=m
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
CONFIG_X86_LONGRUN=y
CONFIG_X86_LONGHAUL=y

#
# shared options
#
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
CONFIG_X86_SPEEDSTEP_LIB=y
# CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_PCI_LEGACY_PROC=y
# CONFIG_PCI_NAMES is not set
# CONFIG_PCI_DEBUG is not set
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DRIVER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_SERIAL=m
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
CONFIG_PARPORT_NOT_PC=y
# CONFIG_PARPORT_GSC is not set
CONFIG_PARPORT_1284=y

#
# Plug and Play support
#
# CONFIG_PNP is not set

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_SX8=m
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
CONFIG_BLK_DEV_IDEFLOPPY=y
CONFIG_BLK_DEV_IDESCSI=m
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_ARM is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=m
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
CONFIG_SCSI_LOGGING=y

#
# SCSI Transport Attributes
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
# CONFIG_SCSI_ISCSI_ATTRS is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
CONFIG_SCSI_SATA=y
# CONFIG_SCSI_SATA_AHCI is not set
# CONFIG_SCSI_SATA_SVW is not set
CONFIG_SCSI_ATA_PIIX=m
# CONFIG_SCSI_SATA_NV is not set
# CONFIG_SCSI_SATA_PROMISE is not set
# CONFIG_SCSI_SATA_QSTOR is not set
# CONFIG_SCSI_SATA_SX4 is not set
# CONFIG_SCSI_SATA_SIL is not set
# CONFIG_SCSI_SATA_SIS is not set
# CONFIG_SCSI_SATA_ULI is not set
# CONFIG_SCSI_SATA_VIA is not set
# CONFIG_SCSI_SATA_VITESSE is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA2XXX=m
# CONFIG_SCSI_QLA21XX is not set
# CONFIG_SCSI_QLA22XX is not set
# CONFIG_SCSI_QLA2300 is not set
# CONFIG_SCSI_QLA2322 is not set
# CONFIG_SCSI_QLA6312 is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
CONFIG_I2O=m
CONFIG_I2O_CONFIG=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_TUNNEL=m
CONFIG_IP_TCPDIAG=y
# CONFIG_IP_TCPDIAG_IPV6 is not set

#
# IP: Virtual Server Configuration
#
CONFIG_IP_VS=m
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12

#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y

#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m

#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
CONFIG_INET6_TUNNEL=m
CONFIG_IPV6_TUNNEL=m
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_CT_ACCT=y
# CONFIG_IP_NF_CONNTRACK_MARK is not set
CONFIG_IP_NF_CT_PROTO_SCTP=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_PHYSDEV=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_REALM=m
CONFIG_IP_NF_MATCH_SCTP=m
CONFIG_IP_NF_MATCH_COMMENT=m
# CONFIG_IP_NF_MATCH_HASHLIMIT is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_NAT_TFTP=m
CONFIG_IP_NF_NAT_AMANDA=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_CLASSIFY=m
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_TARGET_NOTRACK=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m

#
# IPv6: Netfilter Configuration (EXPERIMENTAL)
#
# CONFIG_IP6_NF_QUEUE is not set
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_LIMIT=m
CONFIG_IP6_NF_MATCH_MAC=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_MULTIPORT=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_MARK=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_AHESP=m
CONFIG_IP6_NF_MATCH_LENGTH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_MATCH_PHYSDEV=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_MARK=m
CONFIG_IP6_NF_RAW=m

#
# Bridge: Netfilter Configuration
#
CONFIG_BRIDGE_NF_EBTABLES=m
CONFIG_BRIDGE_EBT_BROUTE=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_BRIDGE_EBT_T_NAT=m
CONFIG_BRIDGE_EBT_802_3=m
CONFIG_BRIDGE_EBT_AMONG=m
CONFIG_BRIDGE_EBT_ARP=m
CONFIG_BRIDGE_EBT_IP=m
CONFIG_BRIDGE_EBT_LIMIT=m
CONFIG_BRIDGE_EBT_MARK=m
CONFIG_BRIDGE_EBT_PKTTYPE=m
CONFIG_BRIDGE_EBT_STP=m
CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_EBT_ARPREPLY=m
CONFIG_BRIDGE_EBT_DNAT=m
CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
# CONFIG_BRIDGE_EBT_ULOG is not set
CONFIG_XFRM=y
CONFIG_XFRM_USER=y

#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y
CONFIG_ATM=m
CONFIG_ATM_CLIP=m
# CONFIG_ATM_CLIP_NO_ICMP is not set
CONFIG_ATM_LANE=m
# CONFIG_ATM_MPOA is not set
CONFIG_ATM_BR2684=m
# CONFIG_ATM_BR2684_IPFILTER is not set
CONFIG_BRIDGE=m
CONFIG_VLAN_8021Q=m
# CONFIG_DECNET is not set
CONFIG_LLC=m
# CONFIG_LLC2 is not set
CONFIG_IPX=m
# CONFIG_IPX_INTERN is not set
CONFIG_ATALK=m
CONFIG_DEV_APPLETALK=y
CONFIG_LTPC=m
CONFIG_COPS=m
CONFIG_COPS_DAYNA=y
CONFIG_COPS_TANGENT=y
CONFIG_IPDDP=m
CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
CONFIG_NET_DIVERT=y
# CONFIG_ECONET is not set
CONFIG_WAN_ROUTER=m

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_ATM=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_BASIC is not set
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_CLS_U32_PERF=y
CONFIG_NET_CLS_IND=y
# CONFIG_CLS_U32_MARK is not set
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
# CONFIG_NET_EMATCH is not set
# CONFIG_NET_CLS_ACT is not set
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_HAMRADIO is not set
CONFIG_IRDA=m

#
# IrDA protocols
#
CONFIG_IRLAN=m
CONFIG_IRCOMM=m
# CONFIG_IRDA_ULTRA is not set

#
# IrDA options
#
CONFIG_IRDA_CACHE_LAST_LSAP=y
CONFIG_IRDA_FAST_RR=y
# CONFIG_IRDA_DEBUG is not set

#
# Infrared-port device drivers
#

#
# SIR device drivers
#
CONFIG_IRTTY_SIR=m

#
# Dongle support
#
CONFIG_DONGLE=y
CONFIG_ESI_DONGLE=m
CONFIG_ACTISYS_DONGLE=m
CONFIG_TEKRAM_DONGLE=m
CONFIG_LITELINK_DONGLE=m
CONFIG_MA600_DONGLE=m
CONFIG_GIRBIL_DONGLE=m
CONFIG_MCP2120_DONGLE=m
CONFIG_OLD_BELKIN_DONGLE=m
CONFIG_ACT200L_DONGLE=m

#
# Old SIR device drivers
#
# CONFIG_IRPORT_SIR is not set

#
# Old Serial dongle support
#

#
# FIR device drivers
#
CONFIG_USB_IRDA=m
CONFIG_SIGMATEL_FIR=m
CONFIG_NSC_FIR=m
# CONFIG_WINBOND_FIR is not set
# CONFIG_TOSHIBA_FIR is not set
# CONFIG_SMC_IRCC_FIR is not set
# CONFIG_ALI_FIR is not set
# CONFIG_VLSI_FIR is not set
# CONFIG_VIA_FIR is not set
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_HIDP=m

#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=m
CONFIG_BT_HCIUSB_SCO=y
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_BCSP_TXCRC=y
CONFIG_BT_HCIBCM203X=m
# CONFIG_BT_HCIBPA10X is not set
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIVHCI=m
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
# CONFIG_NET_ETHERNET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
CONFIG_TIGON3=m

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# ATM drivers
#
# CONFIG_ATM_TCP is not set
# CONFIG_ATM_LANAI is not set
# CONFIG_ATM_ENI is not set
# CONFIG_ATM_FIRESTREAM is not set
# CONFIG_ATM_ZATM is not set
# CONFIG_ATM_NICSTAR is not set
# CONFIG_ATM_IDT77252 is not set
# CONFIG_ATM_AMBASSADOR is not set
# CONFIG_ATM_HORIZON is not set
# CONFIG_ATM_IA is not set
# CONFIG_ATM_FORE200E_MAYBE is not set
# CONFIG_ATM_HE is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
CONFIG_MOUSE_LOGIBM=m
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_ACPI is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_MULTIPORT=y
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
CONFIG_LP_CONSOLE=y
CONFIG_PPDEV=m
# CONFIG_TIPAR is not set

#
# IPMI
#
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
CONFIG_IPMI_WATCHDOG=m
CONFIG_IPMI_POWEROFF=m

#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=m
CONFIG_ACQUIRE_WDT=m
CONFIG_ADVANTECH_WDT=m
CONFIG_ALIM1535_WDT=m
CONFIG_ALIM7101_WDT=m
CONFIG_SC520_WDT=m
CONFIG_EUROTECH_WDT=m
CONFIG_IB700_WDT=m
CONFIG_WAFER_WDT=m
CONFIG_I8XX_TCO=m
CONFIG_SC1200_WDT=m
# CONFIG_60XX_WDT is not set
CONFIG_CPU5_WDT=m
CONFIG_W83627HF_WDT=m
CONFIG_W83877F_WDT=m
CONFIG_MACHZ_WDT=m

#
# ISA-based Watchdog Cards
#
CONFIG_PCWATCHDOG=m
# CONFIG_MIXCOMWD is not set
CONFIG_WDT=m
# CONFIG_WDT_501 is not set

#
# PCI-based Watchdog Cards
#
CONFIG_PCIPCWATCHDOG=m
CONFIG_WDTPCI=m
CONFIG_WDT_501_PCI=y

#
# USB-based Watchdog Cards
#
CONFIG_USBPCWATCHDOG=m
CONFIG_HW_RANDOM=m
CONFIG_NVRAM=m
CONFIG_RTC=y
CONFIG_RTC_HISTOGRAM=y
CONFIG_BLOCKER=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
CONFIG_AGP_INTEL=y
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
CONFIG_DRM_I810=m
CONFIG_DRM_I830=m
CONFIG_DRM_I915=m
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
CONFIG_HANGCHECK_TIMER=y

#
# TPM devices
#
# CONFIG_TCG_TPM is not set

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_ELEKTOR is not set
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_ISA=m
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set

#
# Hardware Sensors Chip support
#
CONFIG_I2C_SENSOR=m
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set

#
# Other I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_RTC8564=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m

#
# Video For Linux
#

#
# Video Adapters
#
# CONFIG_VIDEO_BT848 is not set
# CONFIG_VIDEO_PMS is not set
# CONFIG_VIDEO_BWQCAM is not set
# CONFIG_VIDEO_CQCAM is not set
# CONFIG_VIDEO_W9966 is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
# CONFIG_VIDEO_OVCAMCHIP is not set

#
# Radio Adapters
#
# CONFIG_RADIO_CADET is not set
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
# CONFIG_RADIO_AZTECH is not set
# CONFIG_RADIO_GEMTEK is not set
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_SF16FMR2 is not set
# CONFIG_RADIO_TERRATEC is not set
# CONFIG_RADIO_TRUST is not set
# CONFIG_RADIO_TYPHOON is not set
# CONFIG_RADIO_ZOLTRIX is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_SOFT_CURSOR=y
# CONFIG_FB_MACMODES is not set
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=m
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
# CONFIG_FB_HGA is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
CONFIG_FB_I810=m
CONFIG_FB_I810_GTF=y
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON_OLD is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

#
# Logo configuration
#
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_OHCI_HCD=m
# CONFIG_USB_OHCI_BIG_ENDIAN is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set

#
# USB Device Class drivers
#

#
# USB Bluetooth TTY can only be used with disabled Bluetooth subsystem
#
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
# CONFIG_USB_STORAGE_USBAT is not set
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y

#
# USB Input Devices
#
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
CONFIG_HID_FF=y
CONFIG_HID_PID=y
CONFIG_LOGITECH_FF=y
CONFIG_THRUSTMASTER_FF=y
CONFIG_USB_HIDDEV=y
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set
# CONFIG_USB_VICAM is not set
# CONFIG_USB_DSBR is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_KONICAWC is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_SE401 is not set
# CONFIG_USB_SN9C102 is not set
# CONFIG_USB_STV680 is not set
# CONFIG_USB_PWC is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
CONFIG_USB_MON=y

#
# USB port drivers
#
CONFIG_USB_USS720=m

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
CONFIG_USB_LCD=m
CONFIG_USB_LED=m
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETKIT is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_TEST is not set

#
# USB ATM/DSL drivers
#
# CONFIG_USB_ATM is not set
# CONFIG_USB_SPEEDTOUCH is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS=m
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_REISERFS_FS_SECURITY=y
CONFIG_JFS_FS=m
CONFIG_JFS_POSIX_ACL=y
# CONFIG_JFS_SECURITY is not set
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
CONFIG_FS_POSIX_ACL=y

#
# XFS support
#
CONFIG_XFS_FS=m
CONFIG_XFS_EXPORT=y
# CONFIG_XFS_RT is not set
CONFIG_XFS_QUOTA=y
CONFIG_XFS_SECURITY=y
CONFIG_XFS_POSIX_ACL=y
CONFIG_MINIX_FS=m
CONFIG_ROMFS_FS=m
CONFIG_QUOTA=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="ascii"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS_XATTR=y
CONFIG_DEVPTS_FS_SECURITY=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
CONFIG_AFFS_FS=m
CONFIG_HFS_FS=m
CONFIG_HFSPLUS_FS=m
CONFIG_BEFS_FS=m
# CONFIG_BEFS_DEBUG is not set
CONFIG_BFS_FS=m
CONFIG_EFS_FS=m
CONFIG_CRAMFS=m
CONFIG_VXFS_FS=m
# CONFIG_HPFS_FS is not set
CONFIG_QNX4FS_FS=m
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set

#
# Network File Systems
#
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_RPCSEC_GSS_SPKM3=m
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_CIFS_EXPERIMENTAL is not set
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
CONFIG_EFI_PARTITION=y

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m

#
# Profiling support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=m

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_DEBUG_PREEMPT=y
CONFIG_WAKEUP_TIMING=y
CONFIG_PREEMPT_TRACE=y
# CONFIG_CRITICAL_PREEMPT_TIMING is not set
# CONFIG_CRITICAL_IRQSOFF_TIMING is not set
CONFIG_LATENCY_TIMING=y
# CONFIG_LATENCY_TRACE is not set
CONFIG_RT_DEADLOCK_DETECT=y
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_FS is not set
# CONFIG_USE_FRAME_POINTER is not set
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_KPROBES is not set
CONFIG_DEBUG_STACK_USAGE=y
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_4KSTACKS is not set

#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_CAPABILITIES=y
# CONFIG_SECURITY_ROOTPLUG is not set
# CONFIG_SECURITY_SECLVL is not set
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_WP512=m
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES_586=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_KHAZAD=m
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_CRC32C=m
# CONFIG_CRYPTO_TEST is not set

#
# Hardware crypto devices
#
# CONFIG_CRYPTO_DEV_PADLOCK is not set

#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC32=y
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

Let us know what we should be disabling to get the best performance out
of PREEMPT_RT.

Thanks,

Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || ka...@opersys.com || 1-866-677-4546

Ingo Molnar

unread,
Jun 11, 2005, 2:30:06 PM6/11/05
to

* Karim Yaghmour <ka...@opersys.com> wrote:

> Here's the .config for 2.6.12-rc4-RT-V0.7.47-08:

Thanks. These PREEMPT_RT debugging features should be disabled:

> CONFIG_DEBUG_PREEMPT=y
> CONFIG_WAKEUP_TIMING=y
> CONFIG_PREEMPT_TRACE=y
> CONFIG_LATENCY_TIMING=y
> CONFIG_RT_DEADLOCK_DETECT=y

they all cause significant overhead.

I'd also disable these two security options:

> CONFIG_AUDIT=y
> CONFIG_SECURITY=y

unless you are running an selinux-enabled environment.

i've had not that good experiences with HPET:

> CONFIG_HPET_TIMER=y
> CONFIG_HPET_EMULATE_RTC=y

so i'd disable it - but YMMV.

i'd also disable PAE and use CONFIG_NOHIGHMEM:

> CONFIG_HIGHMEM64G=y

unless you have more than 4GB of RAM. (if you have between 1GB and 4GB
then use HIGHMEM4G)

then i'd disable stack-overflow checking as well:

> CONFIG_DEBUG_STACKOVERFLOW=y
> CONFIG_DEBUG_STACK_USAGE=y

since you are not running 4K stacks.

Ingo

Ingo Molnar

unread,
Jun 11, 2005, 2:50:07 PM6/11/05
to

* Karim Yaghmour <ka...@opersys.com> wrote:

> Here's the .config for 2.6.12-rc4-RT-V0.7.47-08:

find below your .config adopted to the latest -RT patch
(2.6.12-rc6-RT-V0.7.48-11).

I've done one more change relative to the ones described in the previous
mail: i've enabled UP-IOAPIC, which, if the chipset has an IOAPIC, is a
faster interrupt handling method. (otherwise the old PIC will be used
just as fine too and there's no performance penalty from having the
option enabled.) [Note: do not enable the NMI watchdog
(nmi_watchdog=[12]), it will create additional latencies in critical
codepaths.]

Ingo

#
# Automatically generated make config: don't edit

# Linux kernel version: 2.6.12-rc6-RT-V0.7.48-12
# Sat Jun 11 20:19:20 2005


#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_SYSCTL=y

# CONFIG_AUDIT is not set

# CONFIG_HPET_TIMER is not set


# CONFIG_SMP is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT_DESKTOP is not set
CONFIG_PREEMPT_RT=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT_BKL=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ASM_SEMAPHORES=y

CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y


CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set

# CONFIG_X86_MCE_P4THERMAL is not set


CONFIG_TOSHIBA=m
CONFIG_I8K=m
# CONFIG_X86_REBOOTFIXUPS is not set
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m

#
# Firmware Drivers
#
# CONFIG_EDD is not set

CONFIG_NOHIGHMEM=y


# CONFIG_HIGHMEM4G is not set

# CONFIG_HIGHMEM64G is not set

# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set

#

# CONFIG_PCI_MSI is not set

# CONFIG_BNX2 is not set

#

#

# CONFIG_DETECT_SOFTLOCKUP is not set


# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set

# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_WAKEUP_TIMING is not set


# CONFIG_CRITICAL_PREEMPT_TIMING is not set
# CONFIG_CRITICAL_IRQSOFF_TIMING is not set

# CONFIG_RT_DEADLOCK_DETECT is not set
# CONFIG_DEBUG_RT_LOCKING_MODE is not set


# CONFIG_DEBUG_KOBJECT is not set

CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_FS is not set
# CONFIG_USE_FRAME_POINTER is not set
CONFIG_EARLY_PRINTK=y

# CONFIG_DEBUG_STACKOVERFLOW is not set


# CONFIG_KPROBES is not set

# CONFIG_DEBUG_STACK_USAGE is not set


# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_4KSTACKS is not set

CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y

#
# Security options
#
# CONFIG_KEYS is not set

# CONFIG_SECURITY is not set

#

Ingo Molnar

unread,
Jun 11, 2005, 3:30:17 PM6/11/05
to

* Kristian Benoit <kbe...@opersys.com> wrote:

> In the following, interrupts are triggered by the logger at every 1ms.
> It would be interesting to redo such tests with shorter trigger times.
> However, we wanted to keep the logger as "off-the-shelf" as possible.
>
> Interrupt response times (all in micro-seconds):

how were interrupt response times measured, precisely? What did the
target (measured) system have to do to respond to an interrupt? Did you
use the RTC to measure IRQ latencies?

Ingo

Ingo Molnar

unread,
Jun 11, 2005, 3:40:09 PM6/11/05
to

a couple of other wrokloads that are easy to measure and are useful for
triggering worst-case latencies:

hackbench:

http://developer.osdl.org/craiger/hackbench/
http://developer.osdl.org/craiger/hackbench/src/hackbench.c

it creates tons of threads and does message-passing between them. E.g.
"hackbench 50" or "hackbench 100" is a pretty good test.

i use 40 copies of LTP running in parallel:

while true; do ./runalltests.sh -x 40; done

this is good at triggering worst-case latencies too. Plus dbench is good
too:

http://samba.org/ftp/tridge/dbench/
http://samba.org/ftp/tridge/dbench/dbench-3.03.tar.gz

# dbench-3.03> ./dbench 50 -c ./client.txt

also, there's a very good on-host IRQ-latency measurement tool as well:

http://www.affenbande.org/~tapas/wiki/index.php?rtc_wakeup

this uses TSC timestamping to detect wall-clock delays of the RTC
interrupt. The tools jumps through lots of hoops to make sure the
numbers are reliable. If you run it under the -RT kernel then run the
RTC IRQ thread at a higher-than-all-other-threads priority:

chrt -f 95 -p `pidof 'IRQ 8'`
./rtc_wakeup -f 1024 -t 100000

(when you run it, and if you also have RTC_HISTOGRAM enabled in your
.config, then the kernel will print a histogram when you stop
rtc_wakeup, so you've got two sources of information.)

Ingo

Paul E. McKenney

unread,
Jun 11, 2005, 4:20:05 PM6/11/05
to
On Sat, Jun 11, 2005 at 12:36:59AM -0400, Kristian Benoit wrote:
> For the past few weeks, we've been conducting comparison tests between
> PREEMPT_RT and the Adeos nanokernel. As was clear from previous discussion,
> we've been open to be proven wrong regarding endorsement of either method.
> Hence, this comparison was done in order to better understand the impact
> of each method vis-a-vis vanilla Linux.

I took a quick look through, and am quite impressed. I have not yet
had a chance to go through it carefully (much less read the read of
the thread), but wanted to say "thank you!!!" for doing the measurements.

I am sure that there will be some, umm, "controversy" over the benchmark
and measurement methodology, but getting some agreement on what to
measure and how to measure it will be very valuable.

My guess is that there will end up being more than one benchmark, given
the large variety of RT apps out there, but who knows?

Thanx, Paul

Philippe Gerum

unread,
Jun 11, 2005, 6:20:08 PM6/11/05
to

Adeos is a faily simple code, only aimed at creating the "pipeline"
abstraction, which is used to dispatch incoming events to the RT
extension (which provides the co-scheduler) and Linux, according to
their respective priorities. I'm going to build a stripped down version
of the Adeos/x86 patch to only keep the core implementation of the
interrupt pipeline and post it here asap, so that we could further
discuss on actual code.

>
>>In addition, I think the discrepancy between the vanilla kernel and the
>>RT kernel could be much greater, if the workload specifically, or even
>>coincidentally exercised bottlenecks.
>
>
> If you've got any specific test run suggestions, we'll gladly take them.
>
> Karim


--

Philippe.

Karim Yaghmour

unread,
Jun 11, 2005, 6:40:07 PM6/11/05
to

Ingo Molnar wrote:
> find below your .config adopted to the latest -RT patch
> (2.6.12-rc6-RT-V0.7.48-11).

OK thanks, we'll try to use this as-is and also use an as-close-as-possible
version for the Adeos tests that we have something comparable.

Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || ka...@opersys.com || 1-866-677-4546

Karim Yaghmour

unread,
Jun 11, 2005, 6:40:08 PM6/11/05
to

Ingo Molnar wrote:
> how were interrupt response times measured, precisely? What did the
> target (measured) system have to do to respond to an interrupt? Did you
> use the RTC to measure IRQ latencies?

The logger used two TSC values. One prior to shooting the interrupt to the
target, and one when receiving the response. Responding to an interrupt
meant that a driver was hooked to the target's parallel port interrupt and
simply acted by toggling an output pin on the parallel port, which in turn
was hooked onto the logger's parallel port in a similar fashion. We'll
post the code for all components (both logger and target) for everyone to
review. There's no validity in any tests if others can't analyze/criticize/
duplicate.

Karim
--
Author, Speaker, Developer, Consultant

Pushing Embedded and Real-Time Linux Systems Beyond the Limits

http://www.opersys.com || ka...@opersys.com || 1-866-677-4546

Karim Yaghmour

unread,
Jun 11, 2005, 6:50:07 PM6/11/05
to

Paul E. McKenney wrote:
> My guess is that there will end up being more than one benchmark, given
> the large variety of RT apps out there, but who knows?

I don't doubt. We just wanted to get people's attention to such aspects.
We believe that the framework we've built is general enough that others
will find it simple to graft their own tests on top and otherwise extend
it to their needs.

In any case, having more serious benchmarks published will certainly do
no harm.

Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || ka...@opersys.com || 1-866-677-4546

Karim Yaghmour

unread,
Jun 12, 2005, 12:20:05 AM6/12/05
to
[snip]

> this is good at triggering worst-case latencies too. Plus dbench is good
> too:
>
> http://samba.org/ftp/tridge/dbench/
> http://samba.org/ftp/tridge/dbench/dbench-3.03.tar.gz

hackbench and dbench are fine by me, they seem good tests to run.

However ...

> also, there's a very good on-host IRQ-latency measurement tool as well:
>
> http://www.affenbande.org/~tapas/wiki/index.php?rtc_wakeup

This tool I just can't trust. Any software tool that measures the
interrupt latency of the system on which it runs is highly suspect.
There are far too many things happening on the system itself for
the tool to act as an "independent" observer. The only true way to
measure interrupt latency is to have some outside system generate
the interrupts and measure the target system's response time.

In our early tests, we actually had an oscilloscope hooked onto
the target and we had a function generator ready to go for pumping
square waves into the target. However, after spending quite some
time looking at the output on the scope, we concluded that there
was just no way for us to measure the peaks (at least with the
scope we had access to; there are very fancy scopes out there
that can probably do a better job by collecting entire samples,
but we don't have those at hand and so too will it be very likely
that others who want to make such measurements may not have
access to such scopes.) Hence the use of the logger to trigger
and measure interrupts. The logger, target and host setup we
put together can very well be implemented using even antiquated
PCs, something any computer enthusiast can easily obtain very
cheaply at any used computer parts store in their neighborhood.

<background>
A truly hard-rt deterministic system should be very easily
viewed using a function generator and a scope. You pump the
square wave, and the measured system generates a delayed
wave. The interrupt latency is the distance between the two.
You would then be able to increase the square wave's frequency
and see the target system follow, up until it couldn't respond
no more and then by turning the knob down back again, you would
find the nice response square waves again. On modern PCs, even
the hardware isn't deterministic, so you can't see such nice
waves. Instead, you need to collect samples and determine
maximums.
</background>

So hackbench and dbench yes, but rtc_wakeup ... hmm ...

Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || ka...@opersys.com || 1-866-677-4546

Ingo Molnar

unread,
Jun 12, 2005, 2:50:14 AM6/12/05
to

* Karim Yaghmour <ka...@opersys.com> wrote:

> Ingo Molnar wrote:
> > how were interrupt response times measured, precisely? What did the
> > target (measured) system have to do to respond to an interrupt? Did you
> > use the RTC to measure IRQ latencies?
>
> The logger used two TSC values. One prior to shooting the interrupt to
> the target, and one when receiving the response. Responding to an
> interrupt meant that a driver was hooked to the target's parallel port
> interrupt and simply acted by toggling an output pin on the parallel
> port, which in turn was hooked onto the logger's parallel port in a
> similar fashion. We'll post the code for all components (both logger
> and target) for everyone to review. There's no validity in any tests
> if others can't analyze/criticize/ duplicate.

ok, this method should work fine. I suspect you increased the parport
IRQ's priority to the maximum on the PREEMPT_RT kernel, correct? Was
there any userspace thread on the target system (receiving the parport
request and sending the reply), or was it all done in a kernelspace
parport driver?

Ingo

James R Bruce

unread,
Jun 12, 2005, 6:50:09 AM6/12/05
to
Ingo, if you could document the right options required for decent performace somewhere it would be quite helpful (maybe in Documentation/rt-preempt?). My first test of Preempt-RT showed unexpectedly high overhead for a fairly benign network load (120 UDP packets/sec), but that was likely the result of leaving some debugging options on.

I'll try to run an updated test in the near future and see if there are still issues. In the meantime I'll be saving your email to make sure I get the config options right.

- Jim

James R Bruce

unread,
Jun 12, 2005, 7:20:10 AM6/12/05
to
Kristian,
thanks for getting some real response time data, but I have some reproducibility questions. If we look at the following excerpt of your results, check out the max latency column:

Interrupt response times (all in micro-seconds):

+--------------------+------------+------+-------+------+--------+
| Kernel | sys load | Aver | Max | Min | StdDev |
+====================+============+======+=======+======+========+
| | None | 13.4 | 53.3 | 13.2 | 0.2 |
| | Ping | 13.8 | 53.3 | 13.3 | 0.6 |
| with Adeos-r10c3 | lm.+ ping | 13.9 | 21.8 | 13.2 | 0.7 |
| | lmbench | 13.9 | 21.3 | 13.3 | 0.6 |
| | lm. + hd | 13.9 | 53.2 | 13.2 | 0.5 |
+====================+============+======+=======+======+========+

It seems that running lmbench improves the maximum response time considerably compared to an idle system, unless you touch the hard drive. That sort of thing makes very little sense though, and thus is likely an artifact of the testing. Maybe the test needs to be run for longer, or maybe each test should be duplicated a few times? I realize the max is always going to be pretty noisy, but we can't really compare approaches much if it jumps around by a factor of 2.5. Then again, maybe lmbench *does* improve latency and that would definitely be a bug somewhere that you've uncovered :)

The nicest results would be CDFs or histograms of the response times, plotted againts each other for east comparison. Obviously that makes more work for you, however. If we can get full traces from the logger as text, then its easy for us to make such graphs, or add some scripts to your testbed once its released to generate them automatically with gnuplot/etc.

- Jim

P.S. Thanks again for injecting some real numbers into this discussion.

Ingo Molnar

unread,
Jun 12, 2005, 11:00:30 AM6/12/05
to

* James R Bruce <br...@andrew.cmu.edu> wrote:

> Ingo, if you could document the right options required for decent
> performace somewhere it would be quite helpful (maybe in
> Documentation/rt-preempt?). My first test of Preempt-RT showed
> unexpectedly high overhead for a fairly benign network load (120 UDP
> packets/sec), but that was likely the result of leaving some debugging
> options on.

agreed, this needs to be addressed.

in the latest patch (-48-17 or later) i have changed the debugging
options to default to off. (this wont turn them off if your .config has
them turned on already, but will turn them off for new testers'
.configs)

I also added a prominent boot-time message that, if certain
high-overhead debugging options are enabled, says:

*****************************************************************************
* *
* WARNING, the following debugging options are turned on in your .config: *
* *
* CONFIG_DEBUG_RT_LOCKING_MODE *
* CONFIG_RT_DEADLOCK_DETECT *
* CONFIG_DEBUG_PREEMPT *
* CONFIG_CRITICAL_PREEMPT_TIMING *
* CONFIG_CRITICAL_IRQSOFF_TIMING *
* CONFIG_LATENCY_TRACE *
* CONFIG_DEBUG_SLAB *
* *
* they may increase runtime overhead and latencies considerably! *
* *
*****************************************************************************

wrt. documentation - i'm not a big doc writer, but i'm taking patches
:-)

Ingo

Daniel Walker

unread,
Jun 12, 2005, 11:30:12 AM6/12/05
to

On Sun, 12 Jun 2005, Ingo Molnar wrote:

> ok, this method should work fine. I suspect you increased the parport
> IRQ's priority to the maximum on the PREEMPT_RT kernel, correct? Was
> there any userspace thread on the target system (receiving the parport
> request and sending the reply), or was it all done in a kernelspace
> parport driver?

Whatever interrupt is used should be SA_NODELAY if you want maximum
response. The interrupt would need to be validated though , not to lock
mutexes.

Daniel

Philippe Gerum

unread,
Jun 12, 2005, 11:40:06 AM6/12/05
to
Sven-Thorsten Dietrich wrote:
> On Sat, 2005-06-11 at 17:44 +1000, Nick Piggin wrote:
>
>>Ingo Molnar wrote:
>>
>>>could you send me the .config you used for the PREEMPT_RT tests? Also,
>>>you used -47-08, which was well prior the current round of performance
>>>improvements, so you might want to re-run with something like -48-06 or
>>>better.
>>>
>>
>>The other thing that would be really interesting is to test latencies
>>of various other kernel functionalities in the RT kernel (eg. message
>>passing, maybe pipe or localhost read/write, signals, fork/clone/exit,
>>mmap/munmap, faulting in shared memory, or whatever else is important
>>to the RT crowd).
>>
>
>
> I have recently seen an analysis of this. It was internal to a customer,
> but I will ask whether they object to publishing it.
>
> Notably, there are naturally discrepancies between user space and kernel
> tasks. An example of this is thread-spawn benchmarks. That is relevant
> to folks who have RT code with IP to protect that must run in user
> space.
>

This said, running RT tasks in user-space is not uncommon with
nanokernel-based solutions: RTAI does this since 1999, so the "IP"
protection argument does not stand here.

There is a crucial difference between being able to run your RT stuff
under MMU protection with stringent RT guarantees, and being able to
additionally call the native Linux services with the same set of
guarantees. For this reason, keeping the regular programming model in
user-space does not depend on being able to use the kernel services in a
fully deterministic fashion.

IOW, if your RT extension is able to recycle the MMU context of any
Linux task for scheduling it in user-space without stepping on the
kernel toes, you can actually provide for both determinism and
protection (be it MMU or IP), even if you can't make the vanilla kernel
services more deterministic than they are if you happen to call them. If
you don't and always use the highly deterministic services your RT
extension provides, then the RT guarantees are always kept.

Allowing seamless and consistent dynamic transitions between the always
deterministic nanokernel context and the mostly deterministic Linux
context is one way to extend the options available to the RT application
designer. In any case, one would have to carefully select the system
calls which could be used in the application, depending on the expected
level of predictability and time accuracy; using a "pure" Linux
infrastructure or going for a mixed Linux/nanokernel environment never
breaks this invariant.

--

Philippe.

Philippe Gerum

unread,
Jun 12, 2005, 12:00:18 PM6/12/05
to
Kristian Benoit wrote:
> On Sat, 2005-06-11 at 02:15 -0700, Sven-Thorsten Dietrich wrote:
>
>>Its a good start, and its excellent that its being looked at. Thank
>>you
>>guys very much for taking the time to compare these 2 very different
>>systems.
>
>
> Youre welcome !

>
>
>>I think the comparison should absolutely compare identical community
>>kernels. The comparison between two different release candidates is
>>questionable. rc2 to rc4 doesn't seem like much, after all, how much
>>code could go into a release candidate. (diff | wc -l)
>
>
> I agree with that, but as the results show, there does'nt seems to be
> much difference impact the numbers in the tested field.

>
>
>>Also, I question testing -rc code in the first place, except for
>>regression purposes.
>
>
> I tested the -rc code in orther to be able to compare the patched
> kernels against theird own source.

>
>
>>How does that effort compare for porting ADEOS code? If several weeks
>>of
>>work are invested in a comparison of rc2 to rc4, how much additional
>>work is needed to bring Adeos up to the base for the current RT
>>kernel?
>

It has already been done using 2.6.12-rc2/x86 + RT-V0.7.44-03 a few
weeks ago. Since it was the first time such merge was attempted, it took
me a week to get a functional patch which could run a complex "client"
OS such as RTAI over it. Now that the infrastructure is in place, I
guess that the task should be simpler, since hopefully, I now better
understand the implications of having PREEMPT_RT into the kernel codebase.

>
> Philippe, I think that question is youre !

Karim Yaghmour

unread,
Jun 12, 2005, 3:50:09 PM6/12/05
to

Ingo Molnar wrote:
> ok, this method should work fine. I suspect you increased the parport
> IRQ's priority to the maximum on the PREEMPT_RT kernel, correct? Was
> there any userspace thread on the target system (receiving the parport
> request and sending the reply), or was it all done in a kernelspace
> parport driver?

This is all done in kernelspace. I'll check with Kristian for the
rest. In the mean time, let me know if you have any recommendations
based on the fact that it's indeed in the kernel.

Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || ka...@opersys.com || 1-866-677-4546

-

Karim Yaghmour

unread,
Jun 12, 2005, 3:50:10 PM6/12/05
to

James R Bruce wrote:
> It seems that running lmbench improves the maximum response time
> considerably compared to an idle system, unless you touch the
> hard drive. That sort of thing makes very little sense though,
> and thus is likely an artifact of the testing. Maybe the test
> needs to be run for longer, or maybe each test should be
> duplicated a few times? I realize the max is always going to be
> pretty noisy, but we can't really compare approaches much if it
> jumps around by a factor of 2.5. Then again, maybe lmbench *does*
> improve latency and that would definitely be a bug somewhere that
> you've uncovered :)

Actually I personally read these numbers as being very good. What
I see here is that there were exactly two maximums on 5 different
configs and that standard deviation was always close to 0. What that
means is that Adeos' performance degradation is stepwise and can be
studied (i.e. in order to obtain things like: 60% of the time your
maximum will be 53us and 40% of the time, it'll be 22us.) I don't
think there's any correlation between the setup and the maximum
observed. Instead, it's more like ints were generated by the logger
every 1ms and 1ms is an eternity, so on every odd moon, a combination
of factors resulted in the 53 us actually occuring, but on other
setups, with luck, the maximum was less.

The real remedy to this would be to certainly run longer tests, but
more importantly, it would be to generate a lot more interrupts from
the logger at random times instead of just every 1ms. This would
avoid any sort of artificial sync that may occur between the logger
and the target by virtue of having the logger generate interrupts at
exactly every 1ms. This type of test, though, would be more
complicated and it would require very careful design on the logger
side to avoid introducing any sort of articial latency into the
measurement process.

> The nicest results would be CDFs or histograms of the response
> times, plotted againts each other for east comparison. Obviously
> that makes more work for you, however. If we can get full traces
> from the logger as text, then its easy for us to make such graphs,
> or add some scripts to your testbed once its released to generate
> them automatically with gnuplot/etc.

We will be providing full traces, amongst other things. And
getting additions/modifications allowing the automatic generation
of graphs, and other stuff would be great.

Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || ka...@opersys.com || 1-866-677-4546

Paul E. McKenney

unread,
Jun 12, 2005, 4:40:07 PM6/12/05
to
On Sat, Jun 11, 2005 at 06:33:53PM -0400, Karim Yaghmour wrote:
>
> Paul E. McKenney wrote:
> > My guess is that there will end up being more than one benchmark, given
> > the large variety of RT apps out there, but who knows?
>
> I don't doubt. We just wanted to get people's attention to such aspects.
> We believe that the framework we've built is general enough that others
> will find it simple to graft their own tests on top and otherwise extend
> it to their needs.
>
> In any case, having more serious benchmarks published will certainly do
> no harm.

Sounds good, agreed!

Thanx, Paul

Ingo Molnar

unread,
Jun 12, 2005, 5:20:09 PM6/12/05
to

* Karim Yaghmour <ka...@opersys.com> wrote:

> Ingo Molnar wrote:
> > ok, this method should work fine. I suspect you increased the parport
> > IRQ's priority to the maximum on the PREEMPT_RT kernel, correct? Was
> > there any userspace thread on the target system (receiving the parport
> > request and sending the reply), or was it all done in a kernelspace
> > parport driver?
>
> This is all done in kernelspace. I'll check with Kristian for the
> rest. In the mean time, let me know if you have any recommendations
> based on the fact that it's indeed in the kernel.

if you want to measure hw-interrupt delays then under PREEMPT_RT you'll
need to use an SA_NODELAY interrupt handler. (which is a PREEMPT_RT
specific flag) If you use normal request_irq() or some parport driver
then the driver function will run in an interrupt thread and what you
are measuring is not interrupt latency but rescheduling latency.

Ingo

Andrea Arcangeli

unread,
Jun 12, 2005, 6:30:14 PM6/12/05
to
On Sat, Jun 11, 2005 at 06:31:07PM -0400, Karim Yaghmour wrote:
> The logger used two TSC values. One prior to shooting the interrupt to the
> target, and one when receiving the response. Responding to an interrupt

Real life RT apps would run the second rdtsc in user space and not
kernel space, right?

And thanks for your benchmarking efforts!

Sven-Thorsten Dietrich

unread,
Jun 12, 2005, 7:10:08 PM6/12/05
to
On Mon, 2005-06-13 at 00:20 +0200, Andrea Arcangeli wrote:
> On Sat, Jun 11, 2005 at 06:31:07PM -0400, Karim Yaghmour wrote:
> > The logger used two TSC values. One prior to shooting the interrupt to the
> > target, and one when receiving the response. Responding to an interrupt
>
> Real life RT apps would run the second rdtsc in user space and not
> kernel space, right?
>
> And thanks for your benchmarking efforts!

Real-life RT apps are not benchmarks!

There is not requirement for them to run in user space or in kernel
space.

The choice is left to the application designer.

Andrea Arcangeli

unread,
Jun 12, 2005, 8:50:06 PM6/12/05
to
On Sun, Jun 12, 2005 at 10:59:02PM +0200, Ingo Molnar wrote:
> if you want to measure hw-interrupt delays then under PREEMPT_RT you'll
> need to use an SA_NODELAY interrupt handler. (which is a PREEMPT_RT
> specific flag) If you use normal request_irq() or some parport driver
> then the driver function will run in an interrupt thread and what you
> are measuring is not interrupt latency but rescheduling latency.

Karim, just in case you're not very familiar with parport, this should
do the trick:

diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -2286,7 +2286,7 @@ struct parport *parport_pc_probe_port (u
}
if (p->irq != PARPORT_IRQ_NONE) {
if (request_irq (p->irq, parport_pc_interrupt,
- 0, p->name, p)) {
+ SA_NODELAY, p->name, p)) {
printk (KERN_WARNING "%s: irq %d in use, "
"resorting to polled operation\n",
p->name, p->irq);

Unless I'm missing something, this mode is only valid if coding the RT
code in the hardirq handler, which didn't seem the main benefit of
preempt-RT to me, but it's still an interesting basic benchmark,
especially now that local_irq_disable is "soft".

But I'd be nice to also measure the performance of the non-RT part of
the workload, just a suggestion if you have time.

With above patch applied my crystal ball expects preempt-RT to perform
much closer to adeos, but with the difference that the non-RT part of
the system will still get the burden of the added complexity that adeos
won't have.

Thanks.

randy_dunlap

unread,
Jun 12, 2005, 9:00:15 PM6/12/05
to
On Sun, 12 Jun 2005 16:03:41 -0700 Sven-Thorsten Dietrich wrote:

| On Mon, 2005-06-13 at 00:20 +0200, Andrea Arcangeli wrote:
| > On Sat, Jun 11, 2005 at 06:31:07PM -0400, Karim Yaghmour wrote:
| > > The logger used two TSC values. One prior to shooting the interrupt to the
| > > target, and one when receiving the response. Responding to an interrupt
| >
| > Real life RT apps would run the second rdtsc in user space and not
| > kernel space, right?
| >
| > And thanks for your benchmarking efforts!
|
| Real-life RT apps are not benchmarks!
|
| There is not requirement for them to run in user space or in kernel
| space.
|
| The choice is left to the application designer.

Wouldn't the company's attorney/lawyer/counsel be considered too?
After all, in-kernel would likely have some legal ramifications...

---
~Randy

Karim Yaghmour

unread,
Jun 12, 2005, 9:10:07 PM6/12/05
to

randy_dunlap wrote:
> Wouldn't the company's attorney/lawyer/counsel be considered too?
> After all, in-kernel would likely have some legal ramifications...

Sure, but I guess what Sven is trying to say here is that this
stuff is done in kernel-space for benchmarking purposes. How
it's actually used later (user-space vs. kernel-space) is a
separate issue.

Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || ka...@opersys.com || 1-866-677-4546

Karim Yaghmour

unread,
Jun 12, 2005, 9:20:06 PM6/12/05
to

Andrea Arcangeli wrote:
> Karim, just in case you're not very familiar with parport, this should
> do the trick:
>
> diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
> --- a/drivers/parport/parport_pc.c
> +++ b/drivers/parport/parport_pc.c
> @@ -2286,7 +2286,7 @@ struct parport *parport_pc_probe_port (u
> }
> if (p->irq != PARPORT_IRQ_NONE) {
> if (request_irq (p->irq, parport_pc_interrupt,
> - 0, p->name, p)) {
> + SA_NODELAY, p->name, p)) {
> printk (KERN_WARNING "%s: irq %d in use, "
> "resorting to polled operation\n",
> p->name, p->irq);

Thanks for the patch. However, we actually wrote our own driver requesting
the parport int instead of using the one in Linux. We just wanted to
really customize the driver in as much as possible for benchmarking
purposes.

> With above patch applied my crystal ball expects preempt-RT to perform
> much closer to adeos, but with the difference that the non-RT part of
> the system will still get the burden of the added complexity that adeos
> won't have.

We'll be redoing some of the tests, and we'll keep you posted on
the results.

Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || ka...@opersys.com || 1-866-677-4546

Kristian Benoit

unread,
Jun 12, 2005, 10:40:07 PM6/12/05
to

All that sounds like lots of job and fun tomorrow morning. I better go
to sleep !!!

Kristian Benoit

unread,
Jun 12, 2005, 10:50:04 PM6/12/05
to

Thanks, that will help us getting better results from PREEMPT_RT.

Kristian

Ingo Molnar

unread,
Jun 13, 2005, 2:00:16 AM6/13/05
to

* Karim Yaghmour <ka...@opersys.com> wrote:

> > - 0, p->name, p)) {
> > + SA_NODELAY, p->name, p)) {
> > printk (KERN_WARNING "%s: irq %d in use, "
> > "resorting to polled operation\n",
> > p->name, p->irq);
>
> Thanks for the patch. However, we actually wrote our own driver
> requesting the parport int instead of using the one in Linux. We just
> wanted to really customize the driver in as much as possible for
> benchmarking purposes.

in this case you'll still have to use SA_NODELAY - otherwise you'll get
an interrupt thread allocated, whose priority could, depending on the
order of IRQ requests, be lower than the priority of some other
interrupt threads. In that case not only do scheduling latencies get
added to your latency value, but also the worst-case latencies of other
IRQ handlers!

Ingo

Sven-Thorsten Dietrich

unread,
Jun 13, 2005, 3:00:17 AM6/13/05
to
On Sun, 2005-06-12 at 17:53 -0700, randy_dunlap wrote:
> On Sun, 12 Jun 2005 16:03:41 -0700 Sven-Thorsten Dietrich wrote:
>
> | On Mon, 2005-06-13 at 00:20 +0200, Andrea Arcangeli wrote:
> | > On Sat, Jun 11, 2005 at 06:31:07PM -0400, Karim Yaghmour wrote:
> | > > The logger used two TSC values. One prior to shooting the interrupt to the
> | > > target, and one when receiving the response. Responding to an interrupt
> | >
> | > Real life RT apps would run the second rdtsc in user space and not
> | > kernel space, right?
> | >
> | > And thanks for your benchmarking efforts!
> |
> | Real-life RT apps are not benchmarks!
> |
> | There is not requirement for them to run in user space or in kernel
> | space.
> |
> | The choice is left to the application designer.
>
> Wouldn't the company's attorney/lawyer/counsel be considered too?
> After all, in-kernel would likely have some legal ramifications...


Are you talking about SCO legal, FSM labs legal, GPL legal, IP-
protection counseling, or just plain illegal, as in too far out for the
local law man?

Meeting ANY of these requirements in Linux is a challenge to the
software designer, distracting from the RT issues.

Sorry, I don't want to talk about legal cheese.

There are plenty of people working on robotics in college that can use
this code, and they will publish and advance the art of the science,
without legal issues.

To name just one possible application, and only if they sign the patent
form the University requires. Business, they are all still learning
about GPL, and the EU is learning about software patents.

I know some lawyer jokes, and my sister is one attorney I'd never want
to have to argue with in front of a judge, but lets leave the legal
issue out of it, we're trying to do scientific research for the sake of
understanding.

Fear, anxiety, attorneys, patents, lawsuits, and religion all have their
respective venues. Not on this list.

Thanks,

Sven

Ingo Molnar

unread,
Jun 13, 2005, 11:10:08 AM6/13/05
to

* Karim Yaghmour <ka...@opersys.com> wrote:

> Ingo Molnar wrote:
> > how were interrupt response times measured, precisely? What did the
> > target (measured) system have to do to respond to an interrupt? Did you
> > use the RTC to measure IRQ latencies?
>
> The logger used two TSC values. One prior to shooting the interrupt to
> the target, and one when receiving the response. Responding to an
> interrupt meant that a driver was hooked to the target's parallel port
> interrupt and simply acted by toggling an output pin on the parallel
> port, which in turn was hooked onto the logger's parallel port in a

> similar fashion. [...]

FYI, there's a new feature in the -V0.7.48-25 (and later) -RT patches
that implements this: CONFIG_LPPTEST. It is a simple standalone driver
and userspace utility from Thomas Gleixner that can be used to measure
the IRQ-latency of the system over a null-modem-parallel-cable.

to use it, enable CONFIG_LPPEST in the .config [disable CONFIG_PARPORT
first], boot the kernel on both the target and the host systems, and
then run the scripts/testlpp utility on the host system which will
measure latencies and will do a maximum-search.

(the driver assumes normal LPT1 PC layout - 0x378/IRQ7)

Ingo

Kristian Benoit

unread,
Jun 13, 2005, 11:30:17 AM6/13/05
to
On Mon, 2005-06-13 at 17:00 +0200, Ingo Molnar wrote:
> FYI, there's a new feature in the -V0.7.48-25 (and later) -RT patches
> that implements this: CONFIG_LPPTEST. It is a simple standalone
> driver
> and userspace utility from Thomas Gleixner that can be used to
> measure
> the IRQ-latency of the system over a null-modem-parallel-cable.

Thanks a lot, I must check that and make an adeos and adeos/PREEMPT_RT
version of it. That will probably provide different info than the simple
driver I wrote.

Kristian

0 new messages