Re: git guidance
Al Boldi wrote: Willy Tarreau wrote: It should not turn into an endless thread led by people who want to redefine GIT's roadmap, but experience sharing helps a lot with GIT. Well, now that you mentioned it, if there is one thing I dislike, it's for version control to start mutilating your sources. Version Control should be completely transparent. GIT isn't. Thanks! -- Al Care to explain? Git is quite happy handling arbitrary binary content, so I find it difficult to believe that it is changing your source code in strange ways. Rogan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git guidance
Al Boldi wrote: Willy Tarreau wrote: It should not turn into an endless thread led by people who want to redefine GIT's roadmap, but experience sharing helps a lot with GIT. Well, now that you mentioned it, if there is one thing I dislike, it's for version control to start mutilating your sources. Version Control should be completely transparent. GIT isn't. Thanks! -- Al Care to explain? Git is quite happy handling arbitrary binary content, so I find it difficult to believe that it is changing your source code in strange ways. Rogan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: stripping down the kernel-parameters.txt file
Robert P. J. Day wrote: p.s. by "basic", i mean those boot-time parms defined by either "__setup()" or "early_param()". which means that module writers should, as much as possible, stop using those macros to define command-line parameters for their modules. that would go a long way to restoring some order, and allowing for some decent and readable documentation. Are you forgetting that modules can often be compiled into the bzImage, too, making them genuine boot-time params? Rogan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: stripping down the kernel-parameters.txt file
Robert P. J. Day wrote: p.s. by basic, i mean those boot-time parms defined by either __setup() or early_param(). which means that module writers should, as much as possible, stop using those macros to define command-line parameters for their modules. that would go a long way to restoring some order, and allowing for some decent and readable documentation. Are you forgetting that modules can often be compiled into the bzImage, too, making them genuine boot-time params? Rogan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: Only enable autosuspend by default on certain device classes
Matthew Garrett wrote: On Fri, Aug 03, 2007 at 01:44:02PM +0200, Oliver Neukum wrote: Am Freitag 03 August 2007 schrieb Matthew Garrett: It's certainly possible to do that, but it's also possible to have a userspace solution that whitelists devices. The question is whether the default kernel behaviour should be "Save power, but potentially break some of my devices" or "Don't break my devices, but use some more powre". If both options have drawbacks, IMHO we follow the standard, which says that devices must support suspension. Except that lots of hardware doesn't follow the standard in this respect, otherwise we wouldn't be having this discussion. Personally, I think "Will break an unknown number of devices" is a significantly larger drawback than "Will consume a small quantity of additional power". I guess the question could be phrased: Which one is more likely to conclude at some point? That is, if we blacklist by default, we consume that additional power indefinitely, because it is unlikely that people will report "my machine uses 200mW more than I think it should", and thus we are unlikely to build up knowledge of exactly which devices/classes should be blacklisted. Compare that to: "My USB printer broke, guess I'd better report it to LKML". The first option is unlikely to ever reach a satisfactory conclusion, whereas the second one is quite likely to flush out the guilty parties within a relatively short time. FWIW. Rogan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: Only enable autosuspend by default on certain device classes
Matthew Garrett wrote: On Fri, Aug 03, 2007 at 01:44:02PM +0200, Oliver Neukum wrote: Am Freitag 03 August 2007 schrieb Matthew Garrett: It's certainly possible to do that, but it's also possible to have a userspace solution that whitelists devices. The question is whether the default kernel behaviour should be Save power, but potentially break some of my devices or Don't break my devices, but use some more powre. If both options have drawbacks, IMHO we follow the standard, which says that devices must support suspension. Except that lots of hardware doesn't follow the standard in this respect, otherwise we wouldn't be having this discussion. Personally, I think Will break an unknown number of devices is a significantly larger drawback than Will consume a small quantity of additional power. I guess the question could be phrased: Which one is more likely to conclude at some point? That is, if we blacklist by default, we consume that additional power indefinitely, because it is unlikely that people will report my machine uses 200mW more than I think it should, and thus we are unlikely to build up knowledge of exactly which devices/classes should be blacklisted. Compare that to: My USB printer broke, guess I'd better report it to LKML. The first option is unlikely to ever reach a satisfactory conclusion, whereas the second one is quite likely to flush out the guilty parties within a relatively short time. FWIW. Rogan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia ioctl removal
Willy Tarreau wrote:
On Tue, May 01, 2007 at 12:12:36PM +0200, Jan Engelhardt wrote:
On May 1 2007 05:16, Robert P. J. Day wrote:
on the other hand, the features removal file contains the following:
...
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
When: November 2005
...
in other words, the PCMCIA ioctl feature *has* been listed as obsolete
for quite some time, and is already a *year and a half* overdue for
removal.
in short, it's annoying to take the position that stuff can't be
deleted without warning, then turn around and be reluctant to remove
stuff for which *more than ample warning* has already been given.
doing that just makes a joke of the features removal file, and makes
you wonder what its purpose is in the first place.
a little consistency would be nice here, don't you think?
I think this could raise their attention...
init/Makefile
obj-y += obsolete.o
init/obsolete.c:
static __init int obsolete_init(void)
{
printk("\e[1;31m""
The following stuff is gonna get removed \e[5;37m SOON: \e[0m
- cardmgr
- foobar
- bweebol
");
schedule_timeout(3 * HZ);
return;
}
static __exit void obsolete_exit(void) {}
There's something I like here : the fact that all features are centralized
and not hidden in the noise. Clearly we need some standard inside the kernel
to manage obsolete code as well as we currently do by hand.
Willy
The difference between this function and the PCAP/TCPDUMP warning is
that the warning only showed up when the obsolete functionality was
actually used.
Maybe a mechanism to automatically increase the severity of reporting as
the removal date approaches would be an idea? i.e. for each new kernel
that you build leading up the the removal date, a severity is calculated
based on the time until official removal, and then, depending on the
severity, the message can be logged in various ways.
Rogan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia ioctl removal
Willy Tarreau wrote:
On Tue, May 01, 2007 at 12:12:36PM +0200, Jan Engelhardt wrote:
On May 1 2007 05:16, Robert P. J. Day wrote:
on the other hand, the features removal file contains the following:
...
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
When: November 2005
...
in other words, the PCMCIA ioctl feature *has* been listed as obsolete
for quite some time, and is already a *year and a half* overdue for
removal.
in short, it's annoying to take the position that stuff can't be
deleted without warning, then turn around and be reluctant to remove
stuff for which *more than ample warning* has already been given.
doing that just makes a joke of the features removal file, and makes
you wonder what its purpose is in the first place.
a little consistency would be nice here, don't you think?
I think this could raise their attention...
init/Makefile
obj-y += obsolete.o
init/obsolete.c:
static __init int obsolete_init(void)
{
printk(\e[1;31m
The following stuff is gonna get removed \e[5;37m SOON: \e[0m
- cardmgr
- foobar
- bweebol
);
schedule_timeout(3 * HZ);
return;
}
static __exit void obsolete_exit(void) {}
There's something I like here : the fact that all features are centralized
and not hidden in the noise. Clearly we need some standard inside the kernel
to manage obsolete code as well as we currently do by hand.
Willy
The difference between this function and the PCAP/TCPDUMP warning is
that the warning only showed up when the obsolete functionality was
actually used.
Maybe a mechanism to automatically increase the severity of reporting as
the removal date approaches would be an idea? i.e. for each new kernel
that you build leading up the the removal date, a severity is calculated
based on the time until official removal, and then, depending on the
severity, the message can be logged in various ways.
Rogan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [REPORT] cfs-v4 vs sd-0.44
Chris Friesen wrote: Rogan Dawes wrote: I guess my point was if we somehow get to an odd number of nanoseconds, we'd end up with rounding errors. I'm not sure if your algorithm will ever allow that. And Ingo's point was that when it takes thousands of nanoseconds for a single context switch, an error of half a nanosecond is down in the noise. Chris My concern was that since Ingo said that this is a closed economy, with a fixed sum/total, if we lose a nanosecond here and there, eventually we'll lose them all. Some folks have uptimes of multiple years. Of course, I could (very likely!) be full of it! ;-) Rogan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REPORT] cfs-v4 vs sd-0.44
Ingo Molnar wrote:
* Rogan Dawes <[EMAIL PROTECTED]> wrote:
if (p_to && p->wait_runtime > 0) {
p->wait_runtime >>= 1;
p_to->wait_runtime += p->wait_runtime;
}
the above is the basic expression of: "charge a positive bank balance".
[..]
[note, due to the nanoseconds unit there's no rounding loss to worry
about.]
Surely if you divide 5 nanoseconds by 2, you'll get a rounding loss?
yes. But not that we'll only truly have to worry about that when we'll
have context-switching performance in that range - currently it's at
least 2-3 orders of magnitude above that. Microseconds seemed to me to
be too coarse already, that's why i picked nanoseconds and 64-bit
arithmetics for CFS.
Ingo
I guess my point was if we somehow get to an odd number of nanoseconds,
we'd end up with rounding errors. I'm not sure if your algorithm will
ever allow that.
Rogan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [REPORT] cfs-v4 vs sd-0.44
Ingo Molnar wrote:
static void
yield_task_fair(struct rq *rq, struct task_struct *p, struct task_struct *p_to)
{
struct rb_node *curr, *next, *first;
struct task_struct *p_next;
/*
* yield-to support: if we are on the same runqueue then
* give half of our wait_runtime (if it's positive) to the other task:
*/
if (p_to && p->wait_runtime > 0) {
p->wait_runtime >>= 1;
p_to->wait_runtime += p->wait_runtime;
}
the above is the basic expression of: "charge a positive bank balance".
[..]
[note, due to the nanoseconds unit there's no rounding loss to worry
about.]
Surely if you divide 5 nanoseconds by 2, you'll get a rounding loss?
Ingo
Rogan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [REPORT] cfs-v4 vs sd-0.44
Ingo Molnar wrote:
static void
yield_task_fair(struct rq *rq, struct task_struct *p, struct task_struct *p_to)
{
struct rb_node *curr, *next, *first;
struct task_struct *p_next;
/*
* yield-to support: if we are on the same runqueue then
* give half of our wait_runtime (if it's positive) to the other task:
*/
if (p_to p-wait_runtime 0) {
p-wait_runtime = 1;
p_to-wait_runtime += p-wait_runtime;
}
the above is the basic expression of: charge a positive bank balance.
[..]
[note, due to the nanoseconds unit there's no rounding loss to worry
about.]
Surely if you divide 5 nanoseconds by 2, you'll get a rounding loss?
Ingo
Rogan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [REPORT] cfs-v4 vs sd-0.44
Ingo Molnar wrote:
* Rogan Dawes [EMAIL PROTECTED] wrote:
if (p_to p-wait_runtime 0) {
p-wait_runtime = 1;
p_to-wait_runtime += p-wait_runtime;
}
the above is the basic expression of: charge a positive bank balance.
[..]
[note, due to the nanoseconds unit there's no rounding loss to worry
about.]
Surely if you divide 5 nanoseconds by 2, you'll get a rounding loss?
yes. But not that we'll only truly have to worry about that when we'll
have context-switching performance in that range - currently it's at
least 2-3 orders of magnitude above that. Microseconds seemed to me to
be too coarse already, that's why i picked nanoseconds and 64-bit
arithmetics for CFS.
Ingo
I guess my point was if we somehow get to an odd number of nanoseconds,
we'd end up with rounding errors. I'm not sure if your algorithm will
ever allow that.
Rogan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [REPORT] cfs-v4 vs sd-0.44
Chris Friesen wrote: Rogan Dawes wrote: I guess my point was if we somehow get to an odd number of nanoseconds, we'd end up with rounding errors. I'm not sure if your algorithm will ever allow that. And Ingo's point was that when it takes thousands of nanoseconds for a single context switch, an error of half a nanosecond is down in the noise. Chris My concern was that since Ingo said that this is a closed economy, with a fixed sum/total, if we lose a nanosecond here and there, eventually we'll lose them all. Some folks have uptimes of multiple years. Of course, I could (very likely!) be full of it! ;-) Rogan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
H. Peter Anvin wrote: Followup to: <[EMAIL PROTECTED]> By author:Chris Wedgwood <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel On Thu, Apr 07, 2005 at 09:42:04PM -0700, Linus Torvalds wrote: Yes. The silly thing is, at least in my local tests it doesn't actually seem to be _doing_ anything while it's slow (there are no system calls except for a few memory allocations and de-allocations). It seems to have some exponential function on the number of pathnames involved etc. I see lots of brk calls changing the heap size, up, down, up, down, over and over. This smells a bit like c++ new/delete behavior to me. Hmmm... can glibc be clued in to do some hysteresis on the memory allocation? -hpa Take a look at http://www.linuxshowcase.org/2001/full_papers/ezolt/ezolt_html/ Abstract GNU libc's default setting for malloc can cause a significant performance penalty for applications that use it extensively, such as Compaq's high performance extended math library, CXML. The default malloc tuning can cause a significant number of minor page faults, and result in application performance of only half of the true potential. This paper describes how to remove the performance penalty using environmental variables and the method used to discover the cause of the malloc performance penalty. Regards, Rogan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
H. Peter Anvin wrote: Followup to: [EMAIL PROTECTED] By author:Chris Wedgwood [EMAIL PROTECTED] In newsgroup: linux.dev.kernel On Thu, Apr 07, 2005 at 09:42:04PM -0700, Linus Torvalds wrote: Yes. The silly thing is, at least in my local tests it doesn't actually seem to be _doing_ anything while it's slow (there are no system calls except for a few memory allocations and de-allocations). It seems to have some exponential function on the number of pathnames involved etc. I see lots of brk calls changing the heap size, up, down, up, down, over and over. This smells a bit like c++ new/delete behavior to me. Hmmm... can glibc be clued in to do some hysteresis on the memory allocation? -hpa Take a look at http://www.linuxshowcase.org/2001/full_papers/ezolt/ezolt_html/ Abstract GNU libc's default setting for malloc can cause a significant performance penalty for applications that use it extensively, such as Compaq's high performance extended math library, CXML. The default malloc tuning can cause a significant number of minor page faults, and result in application performance of only half of the true potential. This paper describes how to remove the performance penalty using environmental variables and the method used to discover the cause of the malloc performance penalty. Regards, Rogan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
