On Feb 16, 2008 6:14 PM, Alessandro Suardi <[EMAIL PROTECTED]> wrote:
> Feb 16 16:51:49 sandman kernel: BUG: rwlock recursion on CPU#0,
Same thing here, bisected it to:
commit 45b503548210fe6f23e92b856421c2a3f05fd034
Author: Laszlo Attila Toth balabit.hu>
Date: Tue Feb 12 22:42:09 2008 -0800
On Feb 16, 2008 6:14 PM, Alessandro Suardi [EMAIL PROTECTED] wrote:
Feb 16 16:51:49 sandman kernel: BUG: rwlock recursion on CPU#0,
Same thing here, bisected it to:
commit 45b503548210fe6f23e92b856421c2a3f05fd034
Author: Laszlo Attila Toth panther at balabit.hu
Date: Tue Feb 12 22:42:09 2008
On Feb 11, 2008 2:17 PM, rzryyvzy <[EMAIL PROTECTED]> wrote:
> $ cat /proc/fs/vfs/reading_files
>
> $ cat /proc/fs/vfs/writing_files
You can try:
# echo 1 > /proc/sys/vm/block_dump
# dmesg
HTH.
--
Guillaume
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Feb 11, 2008 2:17 PM, rzryyvzy [EMAIL PROTECTED] wrote:
$ cat /proc/fs/vfs/reading_files
$ cat /proc/fs/vfs/writing_files
You can try:
# echo 1 /proc/sys/vm/block_dump
# dmesg
HTH.
--
Guillaume
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On Feb 8, 2008 1:18 PM, <[EMAIL PROTECTED]> wrote:
> Long ago when the CLONE_THREAD support first went it someone thought it
> would be wise to point /proc/self at /proc/ instead of /proc/.
The last message about this conversation is:
http://lkml.org/lkml/2007/12/1/172
So I thought we would
On Feb 8, 2008 1:18 PM, [EMAIL PROTECTED] wrote:
Long ago when the CLONE_THREAD support first went it someone thought it
would be wise to point /proc/self at /proc/tgid instead of /proc/pid.
The last message about this conversation is:
http://lkml.org/lkml/2007/12/1/172
So I thought we would
On Jan 4, 2008 4:19 PM, Al Viro <[EMAIL PROTECTED]> wrote:
> Umm... Actually, m_next() and m_stop() both appear to be too convoluted.
>
> * m_next() never gets v == NULL
> * the only reason why we do that mmput et.al. both from ->next() and
> ->stop() is that we try to avoid having priv->mm;
On Jan 4, 2008 4:19 PM, Al Viro [EMAIL PROTECTED] wrote:
Umm... Actually, m_next() and m_stop() both appear to be too convoluted.
* m_next() never gets v == NULL
* the only reason why we do that mmput et.al. both from -next() and
-stop() is that we try to avoid having priv-mm; why bother?
On 1/31/08, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> hm, this is not a pure elimination of dead code, this will change
> behavior. For example we wont call sched_clock_idle_sleep_event() on
> !cpu_khz now. Hm?
Oops, indeed I overlooked that. OTOH, I can't see how it can happen
(in 32 bit at
On 1/31/08, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> Does something like this help?
I made it compile by open coding undefined macros instead of
refactoring the whole file.
But it didn't affect wake up latencies.
Thanks.
--
Guillaume
--
To unsubscribe from this list: send the line
On 1/31/08, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> works for me :-( (x86_64 rawhide userspace)
i386, !SMP, Fedora 8 here.
> Could you send your .config?
Here we go:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24
# Thu Jan 31 12:33:36 2008
#
#
On Jan 31, 2008 9:55 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> Does this patch from thomas fix it as well?
Unfortunately, not.
For information, reverting just the first part of the offending commit
(sl->timer.cb_mode) fixed the problem, while reverting only the second
part (if
On Jan 31, 2008 9:55 AM, Peter Zijlstra [EMAIL PROTECTED] wrote:
Does this patch from thomas fix it as well?
Unfortunately, not.
For information, reverting just the first part of the offending commit
(sl-timer.cb_mode) fixed the problem, while reverting only the second
part (if
On 1/31/08, Peter Zijlstra [EMAIL PROTECTED] wrote:
works for me :-( (x86_64 rawhide userspace)
i386, !SMP, Fedora 8 here.
Could you send your .config?
Here we go:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24
# Thu Jan 31 12:33:36 2008
#
# CONFIG_64BIT
On 1/31/08, Peter Zijlstra [EMAIL PROTECTED] wrote:
Does something like this help?
I made it compile by open coding undefined macros instead of
refactoring the whole file.
But it didn't affect wake up latencies.
Thanks.
--
Guillaume
--
To unsubscribe from this list: send the line unsubscribe
On 1/31/08, Ingo Molnar [EMAIL PROTECTED] wrote:
hm, this is not a pure elimination of dead code, this will change
behavior. For example we wont call sched_clock_idle_sleep_event() on
!cpu_khz now. Hm?
Oops, indeed I overlooked that. OTOH, I can't see how it can happen
(in 32 bit at least),
On Jan 29, 2008 11:30 PM, Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> ===
> gnome-termina S 0027 0 2201 1
>f6711fb0 00200082 cb330d62 0027 f664105c 0b1e cb331880
>0027 f660d780 009e3840 080ab7d8 080ab298
On Jan 29, 2008 11:30 PM, Guillaume Chazarain [EMAIL PROTECTED] wrote:
===
gnome-termina S 0027 0 2201 1
f6711fb0 00200082 cb330d62 0027 f664105c 0b1e cb331880
0027 f660d780 009e3840 080ab7d8 080ab298 f6711000 c0103e7e
This should be fold into:
4f95bd6e2b21a8c724357463f8341502d47aba13
x86: scale cyc_2_nsec according to CPU frequency
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
---
arch/x86/kernel/tsc_32.c | 14 +-
arch/x86/kernel/tsc_64.c | 14 +-
2 files chang
On Jan 29, 2008 6:47 AM, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> IMHO this is expected results and if someone really needs to cut down
> this latency, they can reduce sysctl_sched_latency (which will be bad
> from perf standpoint, as we will cause more cache thrashing with that).
Thank
On Jan 29, 2008 6:47 AM, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
IMHO this is expected results and if someone really needs to cut down
this latency, they can reduce sysctl_sched_latency (which will be bad
from perf standpoint, as we will cause more cache thrashing with that).
Thank you
This should be fold into:
4f95bd6e2b21a8c724357463f8341502d47aba13
x86: scale cyc_2_nsec according to CPU frequency
Signed-off-by: Guillaume Chazarain [EMAIL PROTECTED]
---
arch/x86/kernel/tsc_32.c | 14 +-
arch/x86/kernel/tsc_64.c | 14 +-
2 files changed, 10
Unfortunately it seems to not be completely fixed, with this script:
#!/usr/bin/python
import os
import time
SLEEP_TIME = 0.1
SAMPLES = 5
PRINT_DELAY = 0.5
def print_wakeup_latency():
times = []
last_print = 0
while True:
start = time.time()
time.sleep(SLEEP_TIME)
Hi Srivatsa,
On Jan 28, 2008 3:31 AM, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> Given that sysctl_sched_wakeup_granularity is set to 10ms by default,
> this doesn't sound abnormal.
Indeed, by lowering sched_wakeup_granularity I get much better
latencies, but lowering sched_latency seems to
Unfortunately it seems to not be completely fixed, with this script:
#!/usr/bin/python
import os
import time
SLEEP_TIME = 0.1
SAMPLES = 5
PRINT_DELAY = 0.5
def print_wakeup_latency():
times = []
last_print = 0
while True:
start = time.time()
time.sleep(SLEEP_TIME)
Hi Srivatsa,
On Jan 28, 2008 3:31 AM, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
Given that sysctl_sched_wakeup_granularity is set to 10ms by default,
this doesn't sound abnormal.
Indeed, by lowering sched_wakeup_granularity I get much better
latencies, but lowering sched_latency seems to be
Hi,
I noticed some strangely high wake up latencies with FAIR_USER_SCHED
using this script:
#!/usr/bin/python
import os
import time
SLEEP_TIME = 0.1
SAMPLES = 100
PRINT_DELAY = 0.5
def print_wakeup_latency():
times = []
last_print = 0
while True:
start = time.time()
Hi,
I noticed some strangely high wake up latencies with FAIR_USER_SCHED
using this script:
#!/usr/bin/python
import os
import time
SLEEP_TIME = 0.1
SAMPLES = 100
PRINT_DELAY = 0.5
def print_wakeup_latency():
times = []
last_print = 0
while True:
start = time.time()
On Jan 25, 2008 5:58 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> sure, done.
Thanks.
> what method are you using of determining quality?
I was talking about code quality: adding a dependency on jiffies does
not seems like a good idea. But also, about the clock quality, I was
focusing on
Hi Ingo,
Can I talk you into dropping these patches of mine from sched-devel
(or not send them to Linus):
da0f9440cdcb1edd5424de91f326de83de3fe5f9 sched: make sure jiffies is
up to date before calling __update_rq_clock()
6eb300ad38fef6db4efe177067a65aaa771596da sched: fix rq->clock
overflows
On Jan 25, 2008 5:58 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
sure, done.
Thanks.
what method are you using of determining quality?
I was talking about code quality: adding a dependency on jiffies does
not seems like a good idea. But also, about the clock quality, I was
focusing on getting
Hi Ingo,
Can I talk you into dropping these patches of mine from sched-devel
(or not send them to Linus):
da0f9440cdcb1edd5424de91f326de83de3fe5f9 sched: make sure jiffies is
up to date before calling __update_rq_clock()
6eb300ad38fef6db4efe177067a65aaa771596da sched: fix rq-clock
overflows
Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> FYI, I'm currently trying to track down where rq->clock started to
> overflow with nohz=off, and it seems to be before 2.6.23, so my patches
> are not at fault ;-) Or maybe I am dreaming and it was always
> overf
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> ok. I have applied all but this one
Hmm, I couldn't find them in mingo/linux-2.6-sched-devel.git.
> i think it's much simpler to do what i have below. Could you try it on
> your box? Or if it is using ACPI idle - in that case the callbacks
> should
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Correction: it was not a high res time source, it was "the scheduler's
> per-cpu, non-exported, non-coherent, warps-and-jumps-like-hell high-res
> timesource that was intentionally called the _sched_ clock" ;-)
I think the warts of cpu_clock() are
David Dillow <[EMAIL PROTECTED]> wrote:
> Patched kernel, nohz=off:
> .clock_underflows : 213887
A little bit of warning about these patches, they are WIP, that's why I
did not send them earlier. It regress nohz=off.
A bit of context: these patches aim at making sure cpu_clock()
David Dillow [EMAIL PROTECTED] wrote:
Patched kernel, nohz=off:
.clock_underflows : 213887
A little bit of warning about these patches, they are WIP, that's why I
did not send them earlier. It regress nohz=off.
A bit of context: these patches aim at making sure cpu_clock() on
Ingo Molnar [EMAIL PROTECTED] wrote:
Correction: it was not a high res time source, it was the scheduler's
per-cpu, non-exported, non-coherent, warps-and-jumps-like-hell high-res
timesource that was intentionally called the _sched_ clock ;-)
I think the warts of cpu_clock() are fixable,
Ingo Molnar [EMAIL PROTECTED] wrote:
ok. I have applied all but this one
Hmm, I couldn't find them in mingo/linux-2.6-sched-devel.git.
i think it's much simpler to do what i have below. Could you try it on
your box? Or if it is using ACPI idle - in that case the callbacks
should already
Guillaume Chazarain [EMAIL PROTECTED] wrote:
FYI, I'm currently trying to track down where rq-clock started to
overflow with nohz=off, and it seems to be before 2.6.23, so my patches
are not at fault ;-) Or maybe I am dreaming and it was always
overflowing. Investigating ...
And the winner
flows as you did.
Thanks.
commit 20fa02359d971bdb820d238184fabd42d8018e4f
Author: Guillaume Chazarain <[EMAIL PROTECTED]>
Date: Thu Jan 10 23:36:43 2008 +0100
sched: monitor clock underflows in /proc/sched_debug
We monitor clock overflows, let's also monitor clock underflow
.
Thanks.
commit 20fa02359d971bdb820d238184fabd42d8018e4f
Author: Guillaume Chazarain [EMAIL PROTECTED]
Date: Thu Jan 10 23:36:43 2008 +0100
sched: monitor clock underflows in /proc/sched_debug
We monitor clock overflows, let's also monitor clock underflows.
Signed-off
the error is combined from the errors in all the synced inodes, so it
just tells that some inode in a specific fs got an error,
- nobody in the call stack is interested in this error: certainly not
pdflush, or 'void sync(2)'.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
---
fs/fs-w
in the call stack is interested in this error: certainly not
pdflush, or 'void sync(2)'.
Signed-off-by: Guillaume Chazarain [EMAIL PROTECTED]
---
fs/fs-writeback.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 0fca820
Al Viro <[EMAIL PROTECTED]> wrote:
> How about this:
At least the task_mmu part works fine.
Tested-by: Guillaume Chazarain <[EMAIL PROTECTED]>
--
Guillaume
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Al Viro <[EMAIL PROTECTED]> wrote:
> vma_stop() doesn't need changes either...
Hmmm, not sure ;-)
$ cat /proc/1/maps
Pid: 2282, comm: cat Not tainted (2.6.24-rc6-gc2 #185)
EIP: 0060:[] EFLAGS: 00010286 CPU: 0
EIP is at vma_stop+0xd/0x21
EAX: f7c90360 EBX: f7c90360 ECX: c042b5f0 EDX:
Return an error instead of successfully reading an empty file.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Acked-by: Al Viro <[EMAIL PROTECTED]>
---
fs/proc/base.c |2 +-
fs/proc/task_mmu.c |6 +++---
fs/proc/task_nommu.c |4 ++--
3 files changed,
urn an error instead of successfully reading an empty file.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
---
fs/proc/base.c |2 +-
fs/proc/task_mmu.c |8 +---
fs/proc/task_nommu.c |4 ++--
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/fs/pro
instead of successfully reading an empty file.
Signed-off-by: Guillaume Chazarain [EMAIL PROTECTED]
---
fs/proc/base.c |2 +-
fs/proc/task_mmu.c |8 +---
fs/proc/task_nommu.c |4 ++--
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
Return an error instead of successfully reading an empty file.
Signed-off-by: Guillaume Chazarain [EMAIL PROTECTED]
Acked-by: Al Viro [EMAIL PROTECTED]
---
fs/proc/base.c |2 +-
fs/proc/task_mmu.c |6 +++---
fs/proc/task_nommu.c |4 ++--
3 files changed, 6 insertions(+), 6
Al Viro [EMAIL PROTECTED] wrote:
vma_stop() doesn't need changes either...
Hmmm, not sure ;-)
$ cat /proc/1/maps
Pid: 2282, comm: cat Not tainted (2.6.24-rc6-gc2 #185)
EIP: 0060:[c01a4080] EFLAGS: 00010286 CPU: 0
EIP is at vma_stop+0xd/0x21
EAX: f7c90360 EBX: f7c90360 ECX: c042b5f0 EDX:
Al Viro [EMAIL PROTECTED] wrote:
How about this:
At least the task_mmu part works fine.
Tested-by: Guillaume Chazarain [EMAIL PROTECTED]
--
Guillaume
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Now that strangers are kept out of /proc//maps, let's welcome them
with -EPERM instead of a blank file.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
---
fs/proc/base.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/
Now that strangers are kept out of /proc/pid/maps, let's welcome them
with -EPERM instead of a blank file.
Signed-off-by: Guillaume Chazarain [EMAIL PROTECTED]
---
fs/proc/base.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
On Dec 13, 2007 2:48 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> 2.6.24-rc5 doesn't seem to create Makefiles in empty obj dirs anymore
Known problem ;-)
See
http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/188cbd12d7c0871b/194fbc7c94314b2c
--
Guillaume
--
To unsubscribe
On Dec 13, 2007 2:48 PM, Andi Kleen [EMAIL PROTECTED] wrote:
2.6.24-rc5 doesn't seem to create Makefiles in empty obj dirs anymore
Known problem ;-)
See
http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/188cbd12d7c0871b/194fbc7c94314b2c
--
Guillaume
--
To unsubscribe from
The patch kbuild: fix building with O=.. options
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=18c32dac75b187d1a4e858f3cfdf03e844129f5e
disabled the creation of a Makefile in a new O=... directory. Restore it.
Signed-off-by: Guillaume Chazarain <[EM
The patch kbuild: fix building with O=.. options
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=18c32dac75b187d1a4e858f3cfdf03e844129f5e
disabled the creation of a Makefile in a new O=... directory. Restore it.
Signed-off-by: Guillaume Chazarain [EMAIL
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> the frequency of both cores is the maximum of what linux sets each core to;
Do you mean that the cpufreq code can be confused about the actual
frequency of the cores? That sounds like a big problem.
Thanks for any insight.
--
Guillaume
--
To
Stefano Brivio <[EMAIL PROTECTED]> wrote:
> Sorry for disappearing. Anyway, yes, those patches fixed it. Precision in
> delays isn't that good when using my crappy unstable TSC (mdelay(2000)
> causes delays between 2 and 2.9 seconds) but it's not depending on frequency
> changes anymore. So I'd
On Dec 10, 2007 9:42 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> although some claimed effect was on udelay()/mdelay() too.
Any specific report?
The jumping sched_clock on frequency change caused some
scheduling oddities for me, but CFS attenuated the effect.
Thanks.
--
Guillaume
--
To
On Dec 10, 2007 9:42 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
although some claimed effect was on udelay()/mdelay() too.
Any specific report?
The jumping sched_clock on frequency change caused some
scheduling oddities for me, but CFS attenuated the effect.
Thanks.
--
Guillaume
--
To
Stefano Brivio [EMAIL PROTECTED] wrote:
Sorry for disappearing. Anyway, yes, those patches fixed it. Precision in
delays isn't that good when using my crappy unstable TSC (mdelay(2000)
causes delays between 2 and 2.9 seconds) but it's not depending on frequency
changes anymore. So I'd say
Arjan van de Ven [EMAIL PROTECTED] wrote:
the frequency of both cores is the maximum of what linux sets each core to;
Do you mean that the cpufreq code can be confused about the actual
frequency of the cores? That sounds like a big problem.
Thanks for any insight.
--
Guillaume
--
To
On Dec 9, 2007 7:01 PM, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > + * ns += offset to avoid sched_clock jumps with cpufreq
> > + *
> > * [EMAIL PROTECTED] "math is hard, lets go shopping!"
> > */
>
> Did john add the 'ns+=' or do comments need reorder?
I added it, but I
On Dec 9, 2007 7:01 PM, Pavel Machek [EMAIL PROTECTED] wrote:
+ * ns += offset to avoid sched_clock jumps with cpufreq
+ *
* [EMAIL PROTECTED] math is hard, lets go shopping!
*/
Did john add the 'ns+=' or do comments need reorder?
I added it, but I think it needs
On Dec 8, 2007 9:52 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> the scariest bit isnt even the scaling i think - that is a fairly
> straightforward and clean PER_CPU-ization of the global scaling factor,
> and its hookup with cpufreq events. (and the credit for that goes to
> G
On Dec 8, 2007 9:52 AM, Ingo Molnar [EMAIL PROTECTED] wrote:
the scariest bit isnt even the scaling i think - that is a fairly
straightforward and clean PER_CPU-ization of the global scaling factor,
and its hookup with cpufreq events. (and the credit for that goes to
Guillaume Chazarain
Le Fri, 7 Dec 2007 15:54:18 +0100,
Ingo Molnar <[EMAIL PROTECTED]> a écrit :
> This is a version that
> is supposed fix all known aspects of TSC and frequency-change
> weirdnesses.
Tested it with frequency changes, the clock is as smooth as I like
it :-)
The only remaining sched_clock user in
Le Fri, 7 Dec 2007 14:55:25 +0100,
Ingo Molnar <[EMAIL PROTECTED]> a écrit :
> Firstly, we dont need the 'offset' anymore because cpu_clock() maintains
> offsets itself.
Yes, but a lower quality one. __update_rq_clock tries to compensate
large jumping clocks with a jiffy resolution, while my
On Dec 7, 2007 12:18 PM, Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> Any pointer to it?
Nevermind, I found it ... in this same thread :-(
--
Guillaume
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTEC
On Dec 7, 2007 12:13 PM, Nick Piggin <[EMAIL PROTECTED]> wrote:
> My patch should fix the worst cpufreq sched_clock jumping issue
> I think.
Any pointer to it?
Thanks.
--
Guillaume
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Le Fri, 7 Dec 2007 09:51:21 +0100,
Ingo Molnar <[EMAIL PROTECTED]> a écrit :
> yeah, we can do something like this in 2.6.25 - this will improve the
> quality of sched_clock().
Thanks a lot for your interest!
I'll clean it up and resend it later. As I don't have the necessary
knowledge to do
"Guillaume Chazarain" <[EMAIL PROTECTED]> wrote:
> On Dec 7, 2007 6:51 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> > Hmrpf. sched_clock() is used for the time stamp of the printks. We
> > need to find some better solution other than killing off the tsc
Le Fri, 7 Dec 2007 14:55:25 +0100,
Ingo Molnar [EMAIL PROTECTED] a écrit :
Firstly, we dont need the 'offset' anymore because cpu_clock() maintains
offsets itself.
Yes, but a lower quality one. __update_rq_clock tries to compensate
large jumping clocks with a jiffy resolution, while my offset
On Dec 7, 2007 12:18 PM, Guillaume Chazarain [EMAIL PROTECTED] wrote:
Any pointer to it?
Nevermind, I found it ... in this same thread :-(
--
Guillaume
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On Dec 7, 2007 12:13 PM, Nick Piggin [EMAIL PROTECTED] wrote:
My patch should fix the worst cpufreq sched_clock jumping issue
I think.
Any pointer to it?
Thanks.
--
Guillaume
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Guillaume Chazarain [EMAIL PROTECTED] wrote:
On Dec 7, 2007 6:51 AM, Thomas Gleixner [EMAIL PROTECTED] wrote:
Hmrpf. sched_clock() is used for the time stamp of the printks. We
need to find some better solution other than killing off the tsc
access completely.
Something like http
Le Fri, 7 Dec 2007 09:51:21 +0100,
Ingo Molnar [EMAIL PROTECTED] a écrit :
yeah, we can do something like this in 2.6.25 - this will improve the
quality of sched_clock().
Thanks a lot for your interest!
I'll clean it up and resend it later. As I don't have the necessary
knowledge to do the
Le Fri, 7 Dec 2007 15:54:18 +0100,
Ingo Molnar [EMAIL PROTECTED] a écrit :
This is a version that
is supposed fix all known aspects of TSC and frequency-change
weirdnesses.
Tested it with frequency changes, the clock is as smooth as I like
it :-)
The only remaining sched_clock user in need
On Dec 7, 2007 6:51 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> Hmrpf. sched_clock() is used for the time stamp of the printks. We
> need to find some better solution other than killing off the tsc
> access completely.
Something like http://lkml.org/lkml/2007/3/16/291 that would need some
On Dec 7, 2007 6:51 AM, Thomas Gleixner [EMAIL PROTECTED] wrote:
Hmrpf. sched_clock() is used for the time stamp of the printks. We
need to find some better solution other than killing off the tsc
access completely.
Something like http://lkml.org/lkml/2007/3/16/291 that would need some
On 11/21/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i guess it was a v2.6.24 change, hence a regression that needs to be
> fixed?
It seems to be
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=01660410
So, linux 2.6.0-test6
--
Guillaume
-
To unsubscribe from this
Hello Eric,
This fills a need I had to get the current TID in a Java program,
so I'm very interested in this change. OTOH, how will someone
not reading LKML discover that the current TID is now in
/proc/self and that it was not always the case?
I would put my 2 cents in /proc/self/task/self,
Hello Eric,
This fills a need I had to get the current TID in a Java program,
so I'm very interested in this change. OTOH, how will someone
not reading LKML discover that the current TID is now in
/proc/self and that it was not always the case?
I would put my 2 cents in /proc/self/task/self,
On 11/21/07, Ingo Molnar [EMAIL PROTECTED] wrote:
i guess it was a v2.6.24 change, hence a regression that needs to be
fixed?
It seems to be
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=01660410
So, linux 2.6.0-test6
--
Guillaume
-
To unsubscribe from this list:
On 11/11/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > So it's not strictly an
> > output directory, more a build directory.
> The opposite
> All output is placed there - including the configuration generated by
> the *config frontends.
I meant, it's not strictly an output directory as if I
On 11/11/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> Another important point is that users that know about and see CONFIG_*
> variables are kernel hackers, not the normal kconfig users.
But kconfig is mainly for kernel hackers, otherwise it would be
called CML2 ;-)
> > Also, when working on a
Hi Adrian,
On 11/11/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> What exactly are the use cases where someone would need this?
Glad you asked. Today, when I want to recompile a kernel while
changing a CONFIG_ option, I manually edit the .config,
remove the appropriate line and then run make
Hi Adrian,
On 11/11/07, Adrian Bunk [EMAIL PROTECTED] wrote:
What exactly are the use cases where someone would need this?
Glad you asked. Today, when I want to recompile a kernel while
changing a CONFIG_ option, I manually edit the .config,
remove the appropriate line and then run make
On 11/11/07, Adrian Bunk [EMAIL PROTECTED] wrote:
Another important point is that users that know about and see CONFIG_*
variables are kernel hackers, not the normal kconfig users.
But kconfig is mainly for kernel hackers, otherwise it would be
called CML2 ;-)
Also, when working on a
On 11/11/07, Sam Ravnborg [EMAIL PROTECTED] wrote:
So it's not strictly an
output directory, more a build directory.
The opposite
All output is placed there - including the configuration generated by
the *config frontends.
I meant, it's not strictly an output directory as if I do
make
Hi,
On 11/10/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> The variable K64BIT can now be used to select the
> value of CONFIG_64BIT.
Why not calling the environment variable CONFIG_64BIT,
in preparation of the day when all CONFIG_ variables can
be passed by environment variables?
--
Guillaume
Hi,
On 11/10/07, Sam Ravnborg [EMAIL PROTECTED] wrote:
The variable K64BIT can now be used to select the
value of CONFIG_64BIT.
Why not calling the environment variable CONFIG_64BIT,
in preparation of the day when all CONFIG_ variables can
be passed by environment variables?
--
Guillaume
-
On 11/6/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> The issue with "make allyesconfig" concerns me, although the same
> situation already exists with any multiple-choice configuration. What I
> guess we really want is to be able to specify a few specific choices.
I don't know enough about
On 11/6/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
The issue with make allyesconfig concerns me, although the same
situation already exists with any multiple-choice configuration. What I
guess we really want is to be able to specify a few specific choices.
I don't know enough about Kbuild to
On 11/2/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> What user-space tools are utilizing delay-accounting by the way?
Thanks for the plugging opportunity ;-)
http://guichaz.free.fr/misc/#iotop uses the I/O side of delay-accounting.
--
Guillaume
-
To unsubscribe from this list: send the line
On 11/2/07, Ingo Molnar [EMAIL PROTECTED] wrote:
What user-space tools are utilizing delay-accounting by the way?
Thanks for the plugging opportunity ;-)
http://guichaz.free.fr/misc/#iotop uses the I/O side of delay-accounting.
--
Guillaume
-
To unsubscribe from this list: send the line
s
than taking the max are needed, but basic testing showed the expected fairness.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
---
include/linux/sched.h |4 ++
kernel/sched.c| 50 +++
kernel/sched_fai
taking the max are needed, but basic testing showed the expected fairness.
Signed-off-by: Guillaume Chazarain [EMAIL PROTECTED]
---
include/linux/sched.h |4 ++
kernel/sched.c| 50 +++
kernel/sched_fair.c | 108 +
3
1 - 100 of 268 matches
Mail list logo
