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
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 n
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 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 remai
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
kern
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 workloa
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 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 a
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 increas
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 O
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 men
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 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
0m7.339s <<< 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 worklo
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 rec
> 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 p
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:27
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 H
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 un
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:
https://www.rtai.org/RT
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
.
I just wanted to 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
variable, instead 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
ed int msecs)
{
timer->expires = 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-La
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: se
lso 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
's small size. 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-Laur
32 matches
Mail list logo
