On Wed, 2007-11-07 at 17:10 -0500, Steven Rostedt wrote:
> >
> > It would be nice if sched_nr_migrate didn't exist, really. It's hard to
> > imagine anyone wanting to tweak it, apart from developers.
>
> I'm not so sure about that. It is a tunable for RT. That is we can tweak
> this value to
On Wed, 2007-11-07 at 17:10 -0500, Steven Rostedt wrote:
It would be nice if sched_nr_migrate didn't exist, really. It's hard to
imagine anyone wanting to tweak it, apart from developers.
I'm not so sure about that. It is a tunable for RT. That is we can tweak
this value to be smaller
On Tue, 2007-10-23 at 20:35 -0600, Matthew Wilcox wrote:
[...]
> > Multiple string objects can share the same data, by increasing the nrefs
> > count, a new data is allocated if the string is modified and nrefs > 1.
>
> If we were trying to get rid of char * throughout the kernel, that might
>
On Tue, 2007-10-23 at 17:12 -0400, Matthew Wilcox wrote:
> Consecutive calls to printk are non-atomic, which leads to various
> implementations for accumulating strings which can be printed in one call.
> This is a generic string buffer which can also be used for non-printk
> purposes. There is
On Tue, 2007-10-23 at 17:12 -0400, Matthew Wilcox wrote:
Consecutive calls to printk are non-atomic, which leads to various
implementations for accumulating strings which can be printed in one call.
This is a generic string buffer which can also be used for non-printk
purposes. There is no
On Tue, 2007-10-23 at 20:35 -0600, Matthew Wilcox wrote:
[...]
Multiple string objects can share the same data, by increasing the nrefs
count, a new data is allocated if the string is modified and nrefs 1.
If we were trying to get rid of char * throughout the kernel, that might
make
On Tue, 2007-10-02 at 11:17 +0200, Thomas Gleixner wrote:
[...]
> I have uploaded an update of the arch/x86 tree based on -rc9 to
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git x86
>
[...]
> If there is anything we can help with the transition, please do not
On Tue, 2007-10-02 at 08:46 +0200, Ingo Molnar wrote:
[...]
> APIs that are not in any real, meaningful use, despite a decade of
> presence are not really interesting to me personally. (especially in
> this case where we know exactly _why_ the API is used so rarely.) Sure
> we'll continue to
On Mon, 2007-10-01 at 16:44 +0200, Ingo Molnar wrote:
> > Adds tunables in sysfs to modify a user's cpu share.
> >
> > A directory is created in sysfs for each new user in the system.
> >
> > /sys/kernel/uids//cpu_share
> >
> > Reading this file returns the cpu shares granted for the user.
On Mon, 2007-10-01 at 16:44 +0200, Ingo Molnar wrote:
Adds tunables in sysfs to modify a user's cpu share.
A directory is created in sysfs for each new user in the system.
/sys/kernel/uids/uid/cpu_share
Reading this file returns the cpu shares granted for the user.
Writing
On Tue, 2007-10-02 at 08:46 +0200, Ingo Molnar wrote:
[...]
APIs that are not in any real, meaningful use, despite a decade of
presence are not really interesting to me personally. (especially in
this case where we know exactly _why_ the API is used so rarely.) Sure
we'll continue to
On Tue, 2007-10-02 at 11:17 +0200, Thomas Gleixner wrote:
[...]
I have uploaded an update of the arch/x86 tree based on -rc9 to
git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git x86
[...]
If there is anything we can help with the transition, please do not
On Wed, 2007-01-08 at 00:46 -0700, Andrew Morton wrote:
> Or you could do something more real-worldly like start up OO, firefox and
> friends, then run /etc/cron.daily/everything and see what the
> before-and-after effects are. The aggregate info we're looking for is
> captured in /proc/meminfo:
On Tue, 2007-31-07 at 23:09 -0700, Andrew Morton wrote:
> +vm-dont-run-touch_buffer-during-buffercache-lookups.patch
>
> A little VM experiment. See changelog for details.
> We don't have any tests to determine the effects of this, and nobody will
> bother setting one up, so ho hum, this
On Tue, 2007-31-07 at 23:09 -0700, Andrew Morton wrote:
+vm-dont-run-touch_buffer-during-buffercache-lookups.patch
A little VM experiment. See changelog for details.
We don't have any tests to determine the effects of this, and nobody will
bother setting one up, so ho hum, this remains
On Wed, 2007-01-08 at 00:46 -0700, Andrew Morton wrote:
Or you could do something more real-worldly like start up OO, firefox and
friends, then run /etc/cron.daily/everything and see what the
before-and-after effects are. The aggregate info we're looking for is
captured in /proc/meminfo:
Related to my other bug report today, calling posix_fadvise (which uses
fadvise64) with the POSIX_FADV_NOREUSE flag does nothing. The pages are
not dropped behind.
I also tried call fadvise with POSIX_FADV_SEQUENTIAL first.
This is expected as the POSIX_FADV_NOREUSE is a no-op in the recent
Linux VM use-once mechanisms don't seem to work. Simple scenario like
streaming a file much greater than physical RAM size should be
identified to avoid trashing the page cache with useless data.
I know the VM cannot predict the future or assume anything about the
user's intent. But this
On Wed, 2007-25-07 at 17:09 +1000, Nick Piggin wrote:
> Eric St-Laurent wrote:
> > I test this on my main system, so patches with basic testing and
> > reasonable stability are preferred. I just want to avoid data corruption
> > bugs. FYI, I used to run the -rt tree most of t
On Wed, 2007-25-07 at 17:09 +1000, Nick Piggin wrote:
Eric St-Laurent wrote:
I test this on my main system, so patches with basic testing and
reasonable stability are preferred. I just want to avoid data corruption
bugs. FYI, I used to run the -rt tree most of the time.
OK here is one
Linux VM use-once mechanisms don't seem to work. Simple scenario like
streaming a file much greater than physical RAM size should be
identified to avoid trashing the page cache with useless data.
I know the VM cannot predict the future or assume anything about the
user's intent. But this
Related to my other bug report today, calling posix_fadvise (which uses
fadvise64) with the POSIX_FADV_NOREUSE flag does nothing. The pages are
not dropped behind.
I also tried call fadvise with POSIX_FADV_SEQUENTIAL first.
This is expected as the POSIX_FADV_NOREUSE is a no-op in the recent
On Thu, 2007-26-07 at 11:00 +0200, Ingo Molnar wrote:
> Subject: sched: make cpu_clock() not use the rq clock
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> it is enough to disable interrupts to get the precise rq-clock
> of the local CPU.
Hi Ingo,
Those new fast nanoseconds resolution clock APIs
On Thu, 2007-26-07 at 11:00 +0200, Ingo Molnar wrote:
Subject: sched: make cpu_clock() not use the rq clock
From: Ingo Molnar [EMAIL PROTECTED]
it is enough to disable interrupts to get the precise rq-clock
of the local CPU.
Hi Ingo,
Those new fast nanoseconds resolution clock APIs are
On Wed, 2007-25-07 at 17:09 +1000, Nick Piggin wrote:
>
> A new list could be a possibility. One problem with adding lists is just
> trying to work out how to balance scanning rates between them, another
> problem is CPU overhead of moving pages from one to another...
Disk sizes seem to
On Wed, 2007-25-07 at 08:47 +0200, Mike Galbraith wrote:
> Heh. Here we have a VM developer expressing his interest in the problem
> space, and you offer him a steaming jug of STFU because he doesn't say
> what you want to hear. I wonder how many killfiles you just entered.
>
Agreed.
(a bit
On Wed, 2007-25-07 at 15:37 +1000, Nick Piggin wrote:
> OK, this is where I start to worry. Swap prefetch AFAIKS doesn't fix
> the updatedb problem very well, because if updatedb has caused swapout
> then it has filled memory, and swap prefetch doesn't run unless there
> is free memory (not to
On Wed, 2007-25-07 at 15:19 +1000, Nick Piggin wrote:
> What *I* think is supposed to happen is that newly read in pages get
> put on the inactive list, and unless they get accessed againbefore
> being reclaimed, they are allowed to fall off the end of the list
> without disturbing active data
On Wed, 2007-25-07 at 15:19 +1000, Nick Piggin wrote:
What *I* think is supposed to happen is that newly read in pages get
put on the inactive list, and unless they get accessed againbefore
being reclaimed, they are allowed to fall off the end of the list
without disturbing active data too
On Wed, 2007-25-07 at 15:37 +1000, Nick Piggin wrote:
OK, this is where I start to worry. Swap prefetch AFAIKS doesn't fix
the updatedb problem very well, because if updatedb has caused swapout
then it has filled memory, and swap prefetch doesn't run unless there
is free memory (not to
On Wed, 2007-25-07 at 08:47 +0200, Mike Galbraith wrote:
Heh. Here we have a VM developer expressing his interest in the problem
space, and you offer him a steaming jug of STFU because he doesn't say
what you want to hear. I wonder how many killfiles you just entered.
Agreed.
(a bit OT)
On Wed, 2007-25-07 at 17:09 +1000, Nick Piggin wrote:
A new list could be a possibility. One problem with adding lists is just
trying to work out how to balance scanning rates between them, another
problem is CPU overhead of moving pages from one to another...
Disk sizes seem to increase
On Wed, 2007-25-07 at 06:55 +0200, Rene Herman wrote:
> It certainly doesn't run for me ever. Always kind of a "that's not the
> point" comment but I just keep wondering whenever I see anyone complain
> about updatedb why the _hell_ they are running it in the first place. If
> anyone who never
On Mon, 2007-23-07 at 19:00 +1000, Nick Piggin wrote:
> I don't like this kind of conditional information going from something
> like readahead into page reclaim. Unless it is for readahead _specific_
> data such as "I got these all wrong, so you can reclaim them" (which
> this isn't).
>
> But I
lt;< Not fixed
4th execution: 0m1.121s
Conclusion:
- The drop-behind patch works and really prevents the page cache content
from being fulled with useless read-once data.
- It doesn't help the copy (read+write) case. This should also be fixed,
as it's a common workload.
Tested-By: Eric St-L
from being fulled with useless read-once data.
- It doesn't help the copy (read+write) case. This should also be fixed,
as it's a common workload.
Tested-By: Eric St-Laurent ([EMAIL PROTECTED])
Best regards,
- Eric
(*) Test program and batch file are attached.
diff -urN linux-2.6/include
On Mon, 2007-23-07 at 19:00 +1000, Nick Piggin wrote:
I don't like this kind of conditional information going from something
like readahead into page reclaim. Unless it is for readahead _specific_
data such as I got these all wrong, so you can reclaim them (which
this isn't).
But I don't
On Wed, 2007-25-07 at 06:55 +0200, Rene Herman wrote:
It certainly doesn't run for me ever. Always kind of a that's not the
point comment but I just keep wondering whenever I see anyone complain
about updatedb why the _hell_ they are running it in the first place. If
anyone who never uses
On Sat, 2007-21-07 at 23:00 +0200, Peter Zijlstra wrote:
> plain text document attachment (readahead-useonce.patch)
> Use the read-ahead code to provide hints to page reclaim.
>
> This patch has the potential to solve the streaming-IO trashes my
> desktop problem.
>
> It tries to aggressively
> They are against git of a few hours ago and the latest readahead patches
> from Wu (which don't apply cleanly either, but the rejects are trivial).
>
> > It would be useful to have a temporary /proc tunable to enable/disable
> > the heuristic to help test the effects.
>
> Right, I had such a
They are against git of a few hours ago and the latest readahead patches
from Wu (which don't apply cleanly either, but the rejects are trivial).
It would be useful to have a temporary /proc tunable to enable/disable
the heuristic to help test the effects.
Right, I had such a patch
On Sat, 2007-21-07 at 23:00 +0200, Peter Zijlstra wrote:
plain text document attachment (readahead-useonce.patch)
Use the read-ahead code to provide hints to page reclaim.
This patch has the potential to solve the streaming-IO trashes my
desktop problem.
It tries to aggressively reclaim
On Tue, 2007-12-06 at 06:00 -0700, Pallipadi, Venkatesh wrote:
>
> >-Original Message-
> Yes. Force_hpet part is should have worked..
> Eric: Can you send me the output of 'lspci -n on your system.
> We need to double check we are covering all ICH7 ids.
Here it is:
00:00.0 0600:
On Sat, 2007-09-06 at 23:05 +0200, Ingo Molnar wrote:
> i'm pleased to announce the v2.6.21.4-rt11 kernel, which can be
> downloaded from the usual place:
>
I'm running 2.6.21.4-rt12-cfs-v17 (x86_64), so far no problems. I like
this kernel a lot, it's feels quite smooth.
One little thing, no
On Sat, 2007-09-06 at 23:05 +0200, Ingo Molnar wrote:
i'm pleased to announce the v2.6.21.4-rt11 kernel, which can be
downloaded from the usual place:
I'm running 2.6.21.4-rt12-cfs-v17 (x86_64), so far no problems. I like
this kernel a lot, it's feels quite smooth.
One little thing, no
On Tue, 2007-12-06 at 06:00 -0700, Pallipadi, Venkatesh wrote:
-Original Message-
Yes. Force_hpet part is should have worked..
Eric: Can you send me the output of 'lspci -n on your system.
We need to double check we are covering all ICH7 ids.
Here it is:
00:00.0 0600: 8086:2770
On Tue, 2007-20-03 at 10:15 +0100, Arjan van de Ven wrote:
> disabling that is a BAD idea. I'm no fan of SMM myself, but it's there,
> and we have to live with it. Disabling it without knowing what it does
> on your system is madness.
>
Like Lee said, for "debugging", mainly trying to resolve
On Tue, 2007-20-03 at 10:15 +0100, Arjan van de Ven wrote:
disabling that is a BAD idea. I'm no fan of SMM myself, but it's there,
and we have to live with it. Disabling it without knowing what it does
on your system is madness.
Like Lee said, for debugging, mainly trying to resolve
On Tue, 2007-20-03 at 01:04 -0400, Lee Revell wrote:
> I think CONFIG_TRY_TO_DISABLE_SMI would be excellent for debugging,
> not to mention people trying to spec out hardware for RT
> applications...
There is a SMI disabling module in RTAI, check the smi-module.c in this:
On Tue, 2007-20-03 at 01:04 -0400, Lee Revell wrote:
I think CONFIG_TRY_TO_DISABLE_SMI would be excellent for debugging,
not to mention people trying to spec out hardware for RT
applications...
There is a SMI disabling module in RTAI, check the smi-module.c in this:
On Sat, 2007-03-03 at 12:29 -0800, Andrew Morton wrote:
> There is much more which could be done to make this code smarter, but I
> think the lesson here is that we can produce a far, far better result doing
> this work in userspace than we could ever hope to do with an in-kernel
>
On Sat, 2007-03-03 at 12:29 -0800, Andrew Morton wrote:
There is much more which could be done to make this code smarter, but I
think the lesson here is that we can produce a far, far better result doing
this work in userspace than we could ever hope to do with an in-kernel
implementation.
point out that while it's good to preserve the current
efficient tick implementation, it may be worthwhile to add a relative
timeout API like Alan Cox proposed a year ago to better hide the
implementation details.
- Eric St-Laurent
-
To unsubscribe from this list: send the line "unsubscrib
that while it's good to preserve the current
efficient tick implementation, it may be worthwhile to add a relative
timeout API like Alan Cox proposed a year ago to better hide the
implementation details.
- Eric St-Laurent
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
ad use jiffies()
(inline or MACRO), IMO monotonic_clock() would be a better name
- provide a relative timeout API (see my previous post, or Alan's
suggestions)
- remove most of the direct use of jiffies through the code and replace
them with msleep(), relative timer, etc
- use human units fo
ires = jiffies + msecs_to_jiffies(msecs);
}
static inline int timeout_expired(struct timeout_timer *timer)
{
return (time_after(jiffies, timer->expires));
}
It provides a nice API for relative timeouts without adding overhead.
- Eric St-Laurent
-
To unsubscribe from this lis
+ msecs_to_jiffies(msecs);
}
static inline int timeout_expired(struct timeout_timer *timer)
{
return (time_after(jiffies, timer-expires));
}
It provides a nice API for relative timeouts without adding overhead.
- Eric St-Laurent
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
or MACRO), IMO monotonic_clock() would be a better name
- provide a relative timeout API (see my previous post, or Alan's
suggestions)
- remove most of the direct use of jiffies through the code and replace
them with msleep(), relative timer, etc
- use human units for those APIs
- Eric St-Laurent
On Mon, 2005-07-11 at 16:08 +0200, Arjan van de Ven wrote:
> Alan: you worked on this before, where did you end up with ?
>
The last patch i've seen is 1 year old.
http://www.ussg.iu.edu/hypermail/linux/kernel/0407.3/0643.html
Eric St-Laurent
-
To unsubscribe from this list: send th
On Mon, 2005-07-11 at 16:08 +0200, Arjan van de Ven wrote:
Alan: you worked on this before, where did you end up with ?
The last patch i've seen is 1 year old.
http://www.ussg.iu.edu/hypermail/linux/kernel/0407.3/0643.html
Eric St-Laurent
-
To unsubscribe from this list: send the line
s also a resolution of 1ms
instead of 10ms.
I remember reading that the multimedia timers are implemented as a high
priority thread.
You can found more details on this site :
http://www.geisswerks.com/ryan/FAQS/timing.html
Best regards,
Eric St-Laurent
-
To unsubscribe from this list: send th
instead of 10ms.
I remember reading that the multimedia timers are implemented as a high
priority thread.
You can found more details on this site :
http://www.geisswerks.com/ryan/FAQS/timing.html
Best regards,
Eric St-Laurent
-
To unsubscribe from this list: send the line unsubscribe linux
ize. With
C++ templates you can have a copy of the routine generated for a
specific datatype, thus skipping the costly function call used for each
compare. With some C macro magic, i presume something similar can be
done, for time-critical applications.
Best regards,
Eric St-Laurent
-
To unsu
a copy of the routine generated for a
specific datatype, thus skipping the costly function call used for each
compare. With some C macro magic, i presume something similar can be
done, for time-critical applications.
Best regards,
Eric St-Laurent
-
To unsubscribe from this list: send the line
64 matches
Mail list logo
