* Re: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio
From: Robert Love @ 2002-12-20 0:29 UTC (permalink / raw)
To: Con Kolivas; +Cc: Andrew Morton, linux kernel mailing list
In-Reply-To: <200212201122.59691.conman@kolivas.net>
On Thu, 2002-12-19 at 19:22, Con Kolivas wrote:
> Is it just because the base timeslices are longer than the old scheduler?
Could be. The default timeslice was around 50ms in 2.4. The default in
2.5 with a min of 10 and a max of 300 is about 100ms.
It could be that without the priority boost, 100ms is too long and
capable of starving tasks (which, without the priority boost, are all at
the same level and thus scheduled round-robin).
Robert Love
^ permalink raw reply
* Re: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio
From: Andrew Morton @ 2002-12-20 0:27 UTC (permalink / raw)
To: Robert Love; +Cc: Con Kolivas, linux kernel mailing list
In-Reply-To: <1040341293.2521.71.camel@phantasy>
Robert Love wrote:
>
> I actually have a 2.5.52 patch out which
> is a bit cleaner - it removes the defines completely and uses the new
> variables.
I actually don't mind the
#define TUNABLE (tunable)
thing, because when you look at the code, it tells you that
TUNABLE is "special". Not a local variable, not a formal arg,
not (really) a global variable. It aids comprehension.
Prefixing all the names with "tune_" would suit, too.
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Pete Zaitcev @ 2002-12-20 0:24 UTC (permalink / raw)
To: Hanna Linder; +Cc: Pete Zaitcev, linux-kernel
In-Reply-To: <62590000.1040343543@w-hlinder>
> Date: Thu, 19 Dec 2002 16:19:03 -0800
> From: Hanna Linder <hannal@us.ibm.com>
> >> Why are bugs automatically assigned to owners?
> >> If there was an unassigned category that would make it
> >> easy to query.
> >
> > Query for "NEW" status for a component and do not put anything
> > into "owner" fireld.
>
> If there was a NEW field that would be exactly what I was
> asking for. When I do a query the only options I see are: OPEN,
> ASSIGNED, RESOLVED, APPROVED, REJECTED, DEFERRED, CLOSED.
> Where is the NEW? Is there somewhere else to do queries?
OK, I'm sorry. This is a little different from what we have at
bugizlla.redhat.com. I suspect OSDL's OPEN roughly corresponds
to NEW. They appear to use Bugzilla which closely resembles the
mother of all them at Mozilla.
> >> Also a list of people who arent maintainers but are available to help
> >> could be useful for the owners to assign bugs to.
> >
> > That's putting a cart in front of a horse. Such people have
> > to execute a simple Bugzilla to get lists, then select bugs
> > which they like. This way the overhead of maintaining such
> > lists disappears instantly.
>
> Im trying to help make it easier for such people to get a list
> of bugs to start working on. If it looks like everything already
> has an owner it looks like there is nothing to do. Im just trying
> to figure out how to use it and hopefully help other people
> do the same thing.
I see the point. I would say, having an owner does not mean
much. Owner is just a person who makes sure bugs do not get lost.
You can work on my bugs if you'd like :)
I understand now that I carry a whole load of misconceptions
caused by extensive use of a slighly different process at Red Hat.
Perhaps we ought to tap into Mozilla people expirience.
-- Pete
^ permalink raw reply
* Re: [ISN] Music file flaws could threaten traders
From: Brian May @ 2002-12-20 0:16 UTC (permalink / raw)
To: Russell Coker; +Cc: selinux
In-Reply-To: <200212192307.20386.russell@coker.com.au>
On Thu, Dec 19, 2002 at 11:07:20PM +0100, Russell Coker wrote:
> On Thu, 19 Dec 2002 09:58, InfoSec News wrote:
> > http://news.com.com/2100-1001-978403.html?tag=fd_top
> >
> > By Robert Lemos
> > Staff Writer, CNET News.com
> > December 18, 2002, 5:12 PM PT
> >
> > A security firm on Wednesday warned that people using Windows XP or
> > popular music player WinAmp could fall prey to a vulnerability,
> > enabling a modified music file to take control of a person's PC.
I think it should be possible to write a program that checks to source
file, makes sure it is valid and doesn't contain any errors or other
potentially dangerous stuff (eg. a multimedia tag with too much data, as
per article), and then relabels it with a file label that allows the
user to freely use that file.
Even better, this program could be generalized to automatically
detect the format, and take appropriate action (eg. virus scanner
for executables, MP3 valididator for MP3 files, etc).
(then again, I am not entirely familiar with MP3 or PNG formats, they
weren't around when I did my University course).
--
Brian May <bam@snoopy.apana.org.au>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio
From: Con Kolivas @ 2002-12-20 0:22 UTC (permalink / raw)
To: Robert Love, Andrew Morton; +Cc: linux kernel mailing list
In-Reply-To: <1040343306.2519.85.camel@phantasy>
>On Thu, 2002-12-19 at 19:02, Andrew Morton wrote:
>> What Con said. When the scheduler makes an inappropriate decision,
>> shortening the timeslice minimises its impact.
>
>OK, I tried it. It does suck.
>
>I wonder why, though, because with the estimator off the scheduler
>should not be making "bad" decisions.
Is it just because the base timeslices are longer than the old scheduler?
Con
^ permalink raw reply
* module loading on demand is not working? 2.5.52-bk4
From: Lukas Hejtmanek @ 2002-12-20 0:16 UTC (permalink / raw)
To: linux-kernel
Hello,
Am I something missing? I'm using nvidia kernel module. I have
alias char-major-195 nvidia
in /etc/modules.conf and /etc/modprobe.conf
but nvidia module is still not loaded on demand.
If I make modprobe nvidia then everything is ok.
--
Lukáš Hejtmánek
^ permalink raw reply
* Re: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio
From: Robert Love @ 2002-12-20 0:16 UTC (permalink / raw)
To: Con Kolivas; +Cc: linux kernel mailing list
In-Reply-To: <200212201104.28863.conman@kolivas.net>
On Thu, 2002-12-19 at 19:04, Con Kolivas wrote:
> Thanks. That looks fair enough. My only concern is that io_load performance is
> worse with lower prio_bonus_ratio settings and io loads are the most felt.
>
> I was thinking of changing what it varied. I was going to leave the timeslice
> fixed and use it to change the prio_bonus_ratio under load. Although that
> kind of defeats the purpose of having it in the first place since it is
> supposed to decide what is interactive under load?
Yep.
You want to find good defaults that just work.
Robert Love
^ permalink raw reply
* Re: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio
From: Robert Love @ 2002-12-20 0:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: Con Kolivas, linux kernel mailing list
In-Reply-To: <3E025E1A.EA32918A@digeo.com>
On Thu, 2002-12-19 at 19:02, Andrew Morton wrote:
> What Con said. When the scheduler makes an inappropriate decision,
> shortening the timeslice minimises its impact.
OK, I tried it. It does suck.
I wonder why, though, because with the estimator off the scheduler
should not be making "bad" decisions.
> > But that in no way precludes not fixing what we have, because good
> > algorithms should not require tuning for common cases. Period.
>
> hm. Good luck ;)
>
> This is a situation in which one is prepares to throw away some cycles
> to achieve a desired effect.
Well one option would be no algorithm at all :)
But if you can find good values that make things run nice, then perhaps
we just need to change the defaults.
I think we should merge sched-tune..
Robert Love
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Hanna Linder @ 2002-12-20 0:19 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: Hanna Linder, linux-kernel
In-Reply-To: <200212192359.gBJNxUI09113@devserv.devel.redhat.com>
--On Thursday, December 19, 2002 06:59:30 PM -0500 Pete Zaitcev <zaitcev@redhat.com> wrote:
>> Why are bugs automatically assigned to owners?
>> If there was an unassigned category that would make it
>> easy to query.
>
> Query for "NEW" status for a component and do not put anything
> into "owner" fireld.
If there was a NEW field that would be exactly what I was
asking for. When I do a query the only options I see are: OPEN,
ASSIGNED, RESOLVED, APPROVED, REJECTED, DEFERRED, CLOSED.
Where is the NEW? Is there somewhere else to do queries?
>> Also a list of people who arent maintainers but are available to help
>> could be useful for the owners to assign bugs to.
>
> That's putting a cart in front of a horse. Such people have
> to execute a simple Bugzilla to get lists, then select bugs
> which they like. This way the overhead of maintaining such
> lists disappears instantly.
Im trying to help make it easier for such people to get a list
of bugs to start working on. If it looks like everything already
has an owner it looks like there is nothing to do. Im just trying
to figure out how to use it and hopefully help other people
do the same thing.
Thanks a lot.
Hanna (obviously not a bugzilla user before)
^ permalink raw reply
* Re: BUG: 2.5.52-bk4
From: Lukas Hejtmanek @ 2002-12-20 0:06 UTC (permalink / raw)
To: Colin Slater; +Cc: linux-kernel
In-Reply-To: <20021219.181921.41185800.hoho@tacomeat.net>
On Thu, Dec 19, 2002 at 06:19:21PM -0500, Colin Slater wrote:
> ===== af_inet.c 1.36 vs edited =====
> --- 1.36/net/ipv4/af_inet.c Sun Nov 24 20:15:49 2002
> +++ edited/af_inet.c Thu Dec 19 18:09:38 2002
+ #include <linux/proc_fs.h>
solved that problem. Now it works ok for me.
...
--
Lukáš Hejtmánek
^ permalink raw reply
* Re: New style dpalloc/hostalloc routines (diff).
From: Paul Mackerras @ 2002-12-19 23:58 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded
In-Reply-To: <3E006C94.2090503@intracom.gr>
Pantelis Antoniou writes:
> +# Support new type of routines, usable from modules
> +bool 'Use new type dpalloc routines()' CONFIG_NEW_DPALLOC
> +bool 'Use new type hostalloc routines()' CONFIG_NEW_HOSTALLOC
> +if [ "$CONFIG_NEW_DPALLOC" = "y" -o "$CONFIG_NEW_HOSTALLOC" = "y" ]; then
> + define_bool CONFIG_CPM_RHEAP y
> +fi
I don't want to see config options that select between different
internal implementations of the same thing. Either your new routines
are better, and we'll use them, or they are worse, and we'll use the
old ones. Having a config option just leads to tons of ifdefs
throughout the code, which makes it harder to read and understand.
Having two implementations of the same thing is just bloat.
Similarly, I don't like the way all your new routines have a "new_"
prefix on the name. You should be thinking of replacing the existing
routines rather than providing an alternative implementation with a
different name. Where you have changed the API, either fix the
drivers or provide a compatibility routine.
The way it looks at the moment, it seems that you don't really have
the conviction that your code is better than what is there already.
Please redo your patch so that it just replaces the old routines. And
please don't send it as a bkpatch since they are impossible to read, a
plain diff -u is much better.
Paul.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [patch][2.5][cft] OSS cs4232.c fix compilation
From: Zwane Mwaikambo @ 2002-12-20 0:08 UTC (permalink / raw)
To: Burton Windle; +Cc: Linux Kernel
Hi Burton,
You'll need the ad1848 patches i posted earlier too.
Regards,
Zwane
Index: linux-2.5.52/sound/oss/cs4232.c
===================================================================
RCS file: /build/cvsroot/linux-2.5.52/sound/oss/cs4232.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 cs4232.c
--- linux-2.5.52/sound/oss/cs4232.c 16 Dec 2002 05:17:07 -0000 1.1.1.1
+++ linux-2.5.52/sound/oss/cs4232.c 19 Dec 2002 22:44:52 -0000
@@ -357,7 +357,7 @@
/* All cs4232 based cards have the main ad1848 card either as CSC0000 or
* CSC0100. */
-static const struct pnp_id cs4232_pnp_table[] = {
+static const struct pnp_device_id cs4232_pnp_table[] = {
{ .id = "CSC0100", .driver_data = 0 },
{ .id = "CSC0000", .driver_data = 0 },
/* Guillemot Turtlebeach something appears to be cs4232 compatible
@@ -368,7 +368,7 @@
/*MODULE_DEVICE_TABLE(isapnp, isapnp_cs4232_list);*/
-static int cs4232_pnp_probe(struct pnp_dev *dev, const struct pnp_id *card_id, const struct pnp_id *dev_id)
+static int cs4232_pnp_probe(struct pnp_dev *dev, const struct pnp_device_id *dev_id)
{
struct address_info *isapnpcfg;
@@ -386,20 +386,19 @@
return -ENODEV;
}
attach_cs4232(isapnpcfg);
- pci_set_drvdata(dev,isapnpcfg);
+ pnp_set_drvdata(dev,isapnpcfg);
return 0;
}
static void cs4232_pnp_remove(struct pnp_dev *dev)
{
- struct address_info *cfg = (struct address_info*) dev->driver_data;
+ struct address_info *cfg = pnp_get_drvdata(dev);
if (cfg)
unload_cs4232(cfg);
}
static struct pnp_driver cs4232_driver = {
.name = "cs4232",
- .card_id_table = NULL,
.id_table = cs4232_pnp_table,
.probe = cs4232_pnp_probe,
.remove = cs4232_pnp_remove,
--
function.linuxpower.ca
^ permalink raw reply
* Re: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio
From: Andrew Morton @ 2002-12-20 0:02 UTC (permalink / raw)
To: Robert Love; +Cc: Con Kolivas, linux kernel mailing list
In-Reply-To: <1040341293.2521.71.camel@phantasy>
Robert Love wrote:
>
> On Thu, 2002-12-19 at 18:18, Andrew Morton wrote:
>
> > That is too often not the case.
>
> I knew you would say that!
>
> > I can get the desktop machine working about as comfortably
> > as 2.4.19 with:
> >
> > # echo 10 > max_timeslice
> > # echo 0 > prio_bonus_ratio
> >
> > ie: disabling all the fancy new scheduler features :(
> >
> > Dropping max_timeslice fixes the enormous stalls which happen
> > when an interactive process gets incorrectly identified as a
> > cpu hog. (OK, that's expected)
>
> Curious why you need to drop max_timeslice, too.
What Con said. When the scheduler makes an inappropriate decision,
shortening the timeslice minimises its impact.
> Did you do that _before_ changing the interactivity estimator?
I disabled the estimator first. The result was amazingly bad ;)
> Dropping max_timeslice
> closer to min_timeslice would do away with a lot of effect of the
> interactivity estimator, since bonuses and penalties would be less
> apparent.
Yup. One good test is to keep rebuilding a kernel all the time,
then just *use* the system. Setting max_timeslice=10, prio_bonus=10
works better still. prio_bonus=25 has small-but-odd lags.
> There would still be (a) the improved priority given to interactive
> processes and (b) the reinsertion into the active away done to
> interactive processes.
>
> Setting prio_bonus_ratio to zero would finish off (a) and (b). It would
> also accomplish the effect of setting max_timeslice low, without
> actually doing it.
>
> Thus, can you try putting max_timeslice back to 300? You would never
> actually use that range, mind you, except for niced/real-time
> processes. But at least then the default timeslice would be a saner
> 100ms.
prio_bonus=0, max_timeslice=300 is awful. Try it...
> ...
> But that in no way precludes not fixing what we have, because good
> algorithms should not require tuning for common cases. Period.
hm. Good luck ;)
This is a situation in which one is prepares to throw away some cycles
to achieve a desired effect.
^ permalink raw reply
* Re: Bug? undefined reference to `input_event'
From: Randy.Dunlap @ 2002-12-20 0:01 UTC (permalink / raw)
To: Justin Pryzby; +Cc: linux-kernel
In-Reply-To: <20021219234705.GA11106@perseus.homeunix.net>
On Thu, 19 Dec 2002, Justin Pryzby wrote:
| Is somebody keeping fixing, or at least keeping track of, these
| configuration errors? I've seen a bunch of configuration problems, and
| the typical response doesn't include a patch (which is fine, as long as
| it ultimately gets fixed). If something can't be configured as a module,
| then it shouldn't be possible to configure it as a module.
That's what the kernel bugzilla is for.
http://bugzilla.kernel.org
or
http://bugme.osdl.org
And some of us are trying to address the issues.
| I can write patches for these things if someone gives me pointers for
| how the 2.{4,5} kernel configuration stuff works.
|
| > Stuff deleted...
--
~Randy
^ permalink raw reply
* Re: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio
From: Con Kolivas @ 2002-12-20 0:04 UTC (permalink / raw)
To: Robert Love; +Cc: linux kernel mailing list
In-Reply-To: <1040341995.2521.81.camel@phantasy>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>On Thu, 2002-12-19 at 18:42, Con Kolivas wrote:
>> I guess this explains why my variable timeslice thingy in -ck helps on the
>> desktop. Basically by shortening the timeslice it is masking the effect of
>> the interactivity estimator under load. That is, it is treating the
>> symptoms of having an interactivity estimator rather than tackling the
>> cause.
>
>You would probably get the same effect or better by setting
>prio_bonus_ratio lower (or off).
>
>Setting it lower will also give less priority bonus/penalty and not
>reinsert the tasks so readily into the active array.
>
>Something like the attached patch may help...
>
> Robert Love
Thanks. That looks fair enough. My only concern is that io_load performance is
worse with lower prio_bonus_ratio settings and io loads are the most felt.
I was thinking of changing what it varied. I was going to leave the timeslice
fixed and use it to change the prio_bonus_ratio under load. Although that
kind of defeats the purpose of having it in the first place since it is
supposed to decide what is interactive under load?
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE+Al6IF6dfvkL3i1gRAo6mAKColJKXyGNaa0dcwot4EvElpHqkawCeORLm
ZSyRVx1w76qWBEgkjbRZWmw=
=ckYA
-----END PGP SIGNATURE-----
^ permalink raw reply
* Tandy 1000 and IBM PS/2
From: Dan Olson @ 2002-12-19 23:53 UTC (permalink / raw)
To: linux-8086
In-Reply-To: <Pine.LNX.4.33.0212060150050.11113-100000@olympus.btstream.com>
Hi,
Sorry if this is already answered somewhere. I have a Tandy 1000
that I'd like to get ELKS on. I remember that there were issues in the
past with the 1000 because it shares video memory with base memory, as the
PCjr does. I know there's been some work on these systems, does ELKS now
work on them by any chance? I also have an IBM PS/2 and I recall the
keyboard didn't work for some reason. The machine is in storage, but I
thought I might as well ask is anyone know the lastest on it too, as both
are somewhat unusual systems. Thanks.
Dan
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Pete Zaitcev @ 2002-12-19 23:59 UTC (permalink / raw)
To: Hanna Linder; +Cc: linux-kernel
In-Reply-To: <mailman.1040338801.24520.linux-kernel2news@redhat.com>
> Why are bugs automatically assigned to owners?
> If there was an unassigned category that would make it
> easy to query.
Query for "NEW" status for a component and do not put anything
into "owner" fireld.
> How else are those of us who want to help stabilize the 2.5 kernel supposed
> to know which bugs are being worked on and which are not?
> (Please dont tell me "email". Am I really supposed to email every
> person who has a bug asking if they are really working on it or not?)
Of course.
> Could you make a list of all the people who have volunteered to be
> bugtracker maintainers and their respective kernel pieces.
This is a reasonable request, IMHO.
> Also a list of people who arent maintainers but are available to help
> could be useful for the owners to assign bugs to.
That's putting a cart in front of a horse. Such people have
to execute a simple Bugzilla to get lists, then select bugs
which they like. This way the overhead of maintaining such
lists disappears instantly.
-- Pete
^ permalink raw reply
* Re: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio
From: Robert Love @ 2002-12-19 23:53 UTC (permalink / raw)
To: Con Kolivas; +Cc: Andrew Morton, linux kernel mailing list
In-Reply-To: <200212201042.48161.conman@kolivas.net>
On Thu, 2002-12-19 at 18:42, Con Kolivas wrote:
> I guess this explains why my variable timeslice thingy in -ck helps on the
> desktop. Basically by shortening the timeslice it is masking the effect of
> the interactivity estimator under load. That is, it is treating the symptoms
> of having an interactivity estimator rather than tackling the cause.
You would probably get the same effect or better by setting
prio_bonus_ratio lower (or off).
Setting it lower will also give less priority bonus/penalty and not
reinsert the tasks so readily into the active array.
Something like the attached patch may help...
Robert Love
--- linux-2.5.52/kernel/sched.c 2002-12-19 18:47:53.000000000 -0500
+++ linux/kernel/sched.c 2002-12-19 18:48:05.000000000 -0500
@@ -66,8 +66,8 @@
int child_penalty = 95;
int parent_penalty = 100;
int exit_weight = 3;
-int prio_bonus_ratio = 25;
-int interactive_delta = 2;
+int prio_bonus_ratio = 5;
+int interactive_delta = 1;
int max_sleep_avg = 2 * HZ;
int starvation_limit = 2 * HZ;
^ permalink raw reply
* ATA/ATAPI-6/7 driver
From: bmoon @ 2002-12-19 23:45 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <3E01FBB9.1410FAB6@speech.mit.edu>
Hello,
I think current linux2.4.20 support ATA-2.
Are there any patches for ATA/ATAPI-6/7?
Thanks,
Bo
^ permalink raw reply
* Re: BUG: 2.5.52-bk4
From: Lukas Hejtmanek @ 2002-12-19 23:49 UTC (permalink / raw)
To: Colin Slater; +Cc: linux-kernel
In-Reply-To: <20021219.181921.41185800.hoho@tacomeat.net>
On Thu, Dec 19, 2002 at 06:19:21PM -0500, Colin Slater wrote:
> if (raw_proc_init())
> goto out_raw;
> - if (tcp_proc_init())
> + if (!proc_net_create("tcp", 0, tcp_get_info))
I have got these:
net/built-in.o(.init.text+0x1489): In function `ipv4_proc_init':
: undefined reference to `proc_net_create'
net/built-in.o(.init.text+0x14be): In function `ipv4_proc_init':
: undefined reference to `proc_net_remove'
make: *** [.tmp_vmlinux1] Error 1
--
Lukáš Hejtmánek
^ permalink raw reply
* Re: Bug? undefined reference to `input_event'
From: Justin Pryzby @ 2002-12-19 23:47 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <2CC936747EA1284DA378A18D730697420158A56F@exchacad.ms.gettysburg.edu>
Is somebody keeping fixing, or at least keeping track of, these
configuration errors? I've seen a bunch of configuration problems, and
the typical response doesn't include a patch (which is fine, as long as
it ultimately gets fixed). If something can't be configured as a module,
then it shouldn't be possible to configure it as a module.
I can write patches for these things if someone gives me pointers for
how the 2.{4,5} kernel configuration stuff works.
Justin
On Thu, Dec 19, 2002 at 06:39:42PM -0500, Bob Miller wrote:
> On Fri, Dec 20, 2002 at 11:22:09AM +1300, mdew wrote:
> > in both the 2.5.52, and bitkeeper trees, i get this error with make
> > bzImage.
> >
> >
> > Generating include/linux/compile.h (updated)
> > gcc -Wp,-MD,init/.version.o.d -D__KERNEL__ -Iinclude -Wall
> > -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
> > -pipe -mpreferred-stack-boundary=2 -march=pentium3
> > -Iarch/i386/mach-generic -fomit-frame-pointer -nostdinc -iwithprefix
> > include -DKBUILD_BASENAME=version -DKBUILD_MODNAME=version -c -o
> > init/version.o init/version.c
> > ld -m elf_i386 -r -o init/built-in.o init/main.o init/version.o
> > init/do_mounts.o init/initramfs.o
> > ld -m elf_i386 -e stext -T arch/i386/vmlinux.lds.s
> > arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/built-in.o
> > --start-group usr/built-in.o arch/i386/kernel/built-in.o
> > arch/i386/mm/built-in.o arch/i386/mach-generic/built-in.o
> > kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o
> > security/built-in.o crypto/built-in.o lib/lib.a arch/i386/lib/lib.a
>
> Stuff deleted...
>
> > #
> > # Input device support
> > #
> > CONFIG_INPUT=m
> >
> > #
> > # Userland interfaces
> > #
> > CONFIG_INPUT_MOUSEDEV=m
> > CONFIG_INPUT_MOUSEDEV_PSAUX=y
> > 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=m
> > # CONFIG_INPUT_EVBUG is not set
> >
> > #
> > # Input I/O drivers
> > #
> > # CONFIG_GAMEPORT is not set
> > CONFIG_SOUND_GAMEPORT=y
> > CONFIG_SERIO=y
> > CONFIG_SERIO_I8042=y
> > CONFIG_SERIO_SERPORT=y
> > # CONFIG_SERIO_CT82C710 is not set
> > # CONFIG_SERIO_PARKBD is not set
> >
> > #
> > # Input Device Drivers
> > #
> > CONFIG_INPUT_KEYBOARD=y
> > CONFIG_KEYBOARD_ATKBD=m
> > # CONFIG_KEYBOARD_SUNKBD is not set
> > # CONFIG_KEYBOARD_XTKBD is not set
> > # CONFIG_KEYBOARD_NEWTON is not set
> > # CONFIG_INPUT_MOUSE is not set
> > # CONFIG_INPUT_JOYSTICK is not set
> > # CONFIG_INPUT_TOUCHSCREEN is not set
> > # CONFIG_INPUT_MISC is not set
> >
>
> CONFIG_INPUT and friends can NOT be configed as modules. They must be
> built into the kernel.
>
> --
> Bob Miller Email: rem@osdl.org
> Open Source Development Lab Phone: 503.626.2455 Ext. 17
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* [BENCHMARK] scheduler tunables with contest - starvation_limit
From: Con Kolivas @ 2002-12-19 23:48 UTC (permalink / raw)
To: linux kernel mailing list; +Cc: Robert Love
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
osdl, contest, tunable - starvation limit on 2.5.52-mm1
noload:
Kernel [runs] Time CPU% Loads LCPU% Ratio
sta_lim1000 [3] 39.7 179 0 0 1.10
sta_lim2000 [3] 39.7 181 0 0 1.10
cacherun:
Kernel [runs] Time CPU% Loads LCPU% Ratio
sta_lim1000 [3] 36.7 194 0 0 1.01
sta_lim2000 [3] 37.0 194 0 0 1.02
process_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
sta_lim1000 [3] 48.2 146 10 47 1.33
sta_lim2000 [3] 45.6 157 7 37 1.26
ctar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
sta_lim1000 [3] 57.9 158 1 10 1.60
sta_lim2000 [3] 54.3 153 1 10 1.50
xtar_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
sta_lim1000 [3] 72.9 125 1 8 2.01
sta_lim2000 [3] 67.6 130 1 9 1.87
io_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
sta_lim1000 [3] 89.6 98 12 19 2.47
sta_lim2000 [3] 79.9 104 11 19 2.21
io_other:
Kernel [runs] Time CPU% Loads LCPU% Ratio
sta_lim1000 [3] 68.1 124 8 19 1.88
sta_lim2000 [3] 68.5 116 9 20 1.89
read_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
sta_lim1000 [3] 49.9 151 5 6 1.38
sta_lim2000 [3] 50.9 150 5 6 1.41
list_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
sta_lim1000 [3] 43.8 167 0 9 1.21
sta_lim2000 [3] 43.5 168 0 9 1.20
mem_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
sta_lim1000 [3] 106.8 77 36 2 2.95
sta_lim2000 [3] 112.4 73 36 2 3.10
Slight balance changes here. Most io things take slightly longer with lower
starvation limit and mem_load takes less time.
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE+AlriF6dfvkL3i1gRAugYAJ93cYDhjqXjM4TIZsLF+zvUtMoJ5QCfS5EC
nIPWPR1JF0awLBCvL1uBzJ4=
=eU+1
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio
From: Robert Love @ 2002-12-19 23:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: Con Kolivas, linux kernel mailing list
In-Reply-To: <3E0253D9.94961FB@digeo.com>
On Thu, 2002-12-19 at 18:18, Andrew Morton wrote:
> That is too often not the case.
I knew you would say that!
> I can get the desktop machine working about as comfortably
> as 2.4.19 with:
>
> # echo 10 > max_timeslice
> # echo 0 > prio_bonus_ratio
>
> ie: disabling all the fancy new scheduler features :(
>
> Dropping max_timeslice fixes the enormous stalls which happen
> when an interactive process gets incorrectly identified as a
> cpu hog. (OK, that's expected)
Curious why you need to drop max_timeslice, too. Did you do that
_before_ changing the interactivity estimator? Dropping max_timeslice
closer to min_timeslice would do away with a lot of effect of the
interactivity estimator, since bonuses and penalties would be less
apparent.
There would still be (a) the improved priority given to interactive
processes and (b) the reinsertion into the active away done to
interactive processes.
Setting prio_bonus_ratio to zero would finish off (a) and (b). It would
also accomplish the effect of setting max_timeslice low, without
actually doing it.
Thus, can you try putting max_timeslice back to 300? You would never
actually use that range, mind you, except for niced/real-time
processes. But at least then the default timeslice would be a saner
100ms.
> I don't expect the interactivity/cpuhog estimator will ever work
> properly on the desktop, frankly. There will always be failure
> cases when a sudden swing in load causes it to make the wrong
> decision.
>
> So it appears that to stem my stream of complaints we need to
> merge scheduler_tunables.patch and edit my /etc/rc.local.
I am glad sched-tune helped identify and fix the issue. I would have no
problem merging this to Linus. I actually have a 2.5.52 patch out which
is a bit cleaner - it removes the defines completely and uses the new
variables. More proper for the long term. Feel free to push what you
have, too.
But that in no way precludes not fixing what we have, because good
algorithms should not require tuning for common cases. Period.
Robert Love
^ permalink raw reply
* Re: [BENCHMARK] scheduler tunables with contest - prio_bonus_ratio
From: Con Kolivas @ 2002-12-19 23:42 UTC (permalink / raw)
To: Andrew Morton, Robert Love; +Cc: linux kernel mailing list
In-Reply-To: <3E0253D9.94961FB@digeo.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>Robert Love wrote:
>> ...
>> Not too sure what to make of it. It shows the interactivity estimator
>> does indeed help... but only if what you consider "important" is what is
>> considered "interactive" by the estimator. Andrew will say that is too
>> often not the case.
>
>That is too often not the case.
>
>I can get the desktop machine working about as comfortably
>as 2.4.19 with:
>
># echo 10 > max_timeslice
># echo 0 > prio_bonus_ratio
>
>ie: disabling all the fancy new scheduler features :(
>
>Dropping max_timeslice fixes the enormous stalls which happen
>when an interactive process gets incorrectly identified as a
>cpu hog. (OK, that's expected)
>
>But when switching virtual desktops some windows still take a
>large fraction of a second to redraw themselves. Disabling the
>interactivity estimator fixes that up too. (Not OK. That's bad)
>
>hm. It's actually quite nice. I'd be prepared to throw away
>a few cycles for this.
>
>I don't expect the interactivity/cpuhog estimator will ever work
>properly on the desktop, frankly. There will always be failure
>cases when a sudden swing in load causes it to make the wrong
>decision.
>
>So it appears that to stem my stream of complaints we need to
>merge scheduler_tunables.patch and edit my /etc/rc.local.
I guess this explains why my variable timeslice thingy in -ck helps on the
desktop. Basically by shortening the timeslice it is masking the effect of
the interactivity estimator under load. That is, it is treating the symptoms
of having an interactivity estimator rather than tackling the cause.
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE+AllzF6dfvkL3i1gRAurrAJ97s1tW96zf+C6NfF2aDpdQM5iUkwCgjxc9
9uNvOEBjvsYIiQxc6yBZcks=
=pvhz
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: RFC: bus_type and device_class merge (or partial merge)
From: Greg KH @ 2002-12-19 23:37 UTC (permalink / raw)
To: Adam J. Richter; +Cc: mochel, linux-kernel
In-Reply-To: <200212192244.OAA06433@adam.yggdrasil.com>
On Thu, Dec 19, 2002 at 02:44:53PM -0800, Adam J. Richter wrote:
> >> = Adam Richter
> > = Patrick Mochel
>
> >Especially during the continuing evolution
> >of the model. At least for now, and for probably a very long time, I will
> >not consider patches to consolidate the two object types.
>
> Linux will be better if we decide things by weighing technical
> benefits rather than by attempts at diktat. I recommend you keep an
> open mind about it.
Heh, if anyone has kept an open mind around here, it's Pat. Look at the
crap that the driver writers have forced him to accommodate. Here's a
small drawing that some people did at OLS 2002 to help get across how
all of the wide range of busses, classes, devices, and drivers interact
with just one kind of subsystem:
http://www.kroah.com/linux/images/driver_model_1_ols_2002.jpg
The existing code handles monstrosities like that quite well, because he
has kept an open mind, and listened to the driver and subsystem authors.
And yes, we need to start writing more class support, it's next on my
list too. Patches to do this would be greatly appreciated.
thanks,
greg k-h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.