On Wed, 25 Jul 2007 13:34:01 +0200, Ingo Molnar said:
Maybe the kernel could be extended with a method of opening files in a
'drop from the dcache after use' way. (beagled and backup tools could
make use of that facility too.) (Or some other sort of
file-cache-invalidation syscall that
Hey Eric,
On 7/24/07, Nick Piggin [EMAIL PROTECTED] wrote:
Eric St-Laurent wrote:
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
On 7/24/07, Nick Piggin [EMAIL PROTECTED] wrote:
Ray Lee wrote:
On 7/23/07, Nick Piggin [EMAIL PROTECTED] wrote:
If we can first try looking at
some specific problems that are easily identified.
Always easier, true. Let's start with My mouse jerks around under
memory load. A Google Summer
On 7/25/07, Ingo Molnar [EMAIL PROTECTED] wrote:
* Kacper Wysocki [EMAIL PROTECTED] wrote:
[snip howto get a patch merged]
But a here is a solution, take it or leave it approach, before
having communicated the problem to the maintainer and before having
debugged the problem is the
On 7/25/07, Rene Herman [EMAIL PROTECTED] wrote:
And there we go again -- off into blabber-land. Why does swap-prefetch help
updatedb? Or doesn't it? And if it doesn't, why should anyone trust anything
else someone who said it does says?
I don't think anyone has ever argued that swap-prefetch
Hi Ingo,
[ Going off-topic, nothing related to swap/prefetch/etc. Just getting
a hang of how development goes on here ... ]
On 7/25/07, Ingo Molnar [EMAIL PROTECTED] wrote:
* Rene Herman [EMAIL PROTECTED] wrote:
Nick Piggin is the person to convince it seems and if I've read things
right
On Wed, 2007-07-25 at 09:02 -0700, Ray Lee wrote:
I'd just like updatedb to amortize its work better. If we had some way
to track all filesystem events, updatedb could keep a live and
accurate index on the filesystem. And this isn't just updatedb that
wants that, beagle and tracker et al also
Nick Piggin [EMAIL PROTECTED] writes:
Ray Lee wrote:
On 7/23/07, Nick Piggin [EMAIL PROTECTED] wrote:
Also a random day at the desktop, it is quite a broad scope and
pretty well impossible to analyse.
It is pretty broad, but that's also what swap prefetch is targetting.
As for hard
Question:
Could those who have found this prefetch helps them alot say how
many disks they have? In particular, is their swap on the same
disk spindle as their root and user files?
Answer - for me:
On my system where updatedb is a big problem, I have one, slow, disk.
On both desktop
On 7/25/07, Zan Lynx [EMAIL PROTECTED] wrote:
On Wed, 2007-07-25 at 09:02 -0700, Ray Lee wrote:
I'd just like updatedb to amortize its work better. If we had some way
to track all filesystem events, updatedb could keep a live and
accurate index on the filesystem. And this isn't just updatedb
On 7/26/07, Ray Lee [EMAIL PROTECTED] wrote:
I'd just like updatedb to amortize its work better. If we had some way
to track all filesystem events, updatedb could keep a live and
accurate index on the filesystem. And this isn't just updatedb that
wants that, beagle and tracker et al also want to
On 7/25/07, Matthew Hawkins [EMAIL PROTECTED] wrote:
On 7/26/07, Ray Lee [EMAIL PROTECTED] wrote:
I'd just like updatedb to amortize its work better. If we had some way
to track all filesystem events, updatedb could keep a live and
accurate index on the filesystem. And this isn't just
Hi,
Some general thoughts about submitter/maintainer responsibilities,
not necessarily connected with the recents events (I hasn't been
following them closely - some people don't have that much free time
to burn at their hands ;)...
On Wednesday 25 July 2007, Ingo Molnar wrote:
* Satyam
Ray Lee wrote:
On 7/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
by the way, I've also seen comments on the Postgres performance mailing
list about how slow linux is compared to other OS's in pulling data back
in that's been pushed out to swap (not a factor on dedicated database
and the fact is: updatedb discards a considerable portion of the cache
completely unnecessarily: on a reasonably complex box no way do all the
I'm wondering how much of this updatedb problem is due to poor layout
of swap and other file systems across disk spindles.
I'll wager that those most
Andrew Morton wrote:
All this would end up needing runtime configurability and tweakability and
customisability. All standard fare for userspace stuff - much easier than
patching the kernel.
So. We can
a) provide a way for userspace to reload pagecache and
b) merge maps2 (once it's
Bartlomiej Zolnierkiewicz wrote:
On Wednesday 25 July 2007, Ingo Molnar wrote:
you dont _have to_ cooperative with the maintainer, but it's certainly
useful to work with good maintainers, if your goal is to improve Linux.
Or if for some reason communication is not working out fine then grow
* Satyam Sharma [EMAIL PROTECTED] wrote:
concentrate on making sure that both you and the maintainer
understands the problem correctly,
This itself may require some convincing to do. What if the
maintainer just doesn't recognize the problem? Note that the
development model here is
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 mention that updatedb would have paged out
On Wed, 2007-07-25 at 15:05 -0700, Paul Jackson wrote:
[snip]
Question:
Could those who have found this prefetch helps them alot say how
many disks they have? In particular, is their swap on the same
disk spindle as their root and user files?
Answer - for me:
On my system where
On 7/25/07, Paul Jackson [EMAIL PROTECTED] wrote:
Question:
Could those who have found this prefetch helps them alot say how
many disks they have? In particular, is their swap on the same
disk spindle as their root and user files?
I have found that swap prefetch helped on all of the
On 7/26/07, Ray Lee [EMAIL PROTECTED] wrote:
Yeah, I know about inotify, but it doesn't scale.
Yeah, the nonrecursive behaviour is a bugger. Also I found it helped
to queue operations in userspace and execute periodically rather than
trying to execute on every single notification. Worked well
On 26/07/07, Paul Jackson [EMAIL PROTECTED] wrote:
and the fact is: updatedb discards a considerable portion of the cache
completely unnecessarily: on a reasonably complex box no way do all the
I'm wondering how much of this updatedb problem is due to poor layout
of swap and other file
On Wed, 25 Jul 2007 09:09:01 -0700
Ray Lee [EMAIL PROTECTED] wrote:
No, there's a third case which I find the most annoying. I have
multiple working sets, the sum of which won't fit into RAM. When I
finish one, the kernel had time to preemptively swap back in the
other, and yet it didn't. So,
On Wed, 25 Jul 2007, Nick Piggin wrote:
Eric St-Laurent wrote:
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
On Wed, 25 Jul 2007, Rene Herman wrote:
On 07/25/2007 07:12 AM, [EMAIL PROTECTED] wrote:
On Wed, 25 Jul 2007, 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
Eric St-Laurent wrote:
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
On 07/25/2007 07:12 AM, [EMAIL PROTECTED] wrote:
On Wed, 25 Jul 2007, 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
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 Wed, 25 Jul 2007, Rene Herman wrote:
On 07/25/2007 06:06 AM, Nick Piggin wrote:
Ray Lee wrote:
> Anyway, my point is that I worry that tuning for an unusual and
> infrequent workload (which updatedb certainly is), is the wrong way to
> go.
Well it runs every day or so for every
Rene Herman wrote:
On 07/25/2007 06:06 AM, Nick Piggin wrote:
Ray Lee wrote:
Anyway, my point is that I worry that tuning for an unusual and
infrequent workload (which updatedb certainly is), is the wrong way
to go.
Well it runs every day or so for every desktop Linux user, and it has
On 07/25/2007 06:06 AM, Nick Piggin wrote:
Ray Lee wrote:
Anyway, my point is that I worry that tuning for an unusual and
infrequent workload (which updatedb certainly is), is the wrong way to
go.
Well it runs every day or so for every desktop Linux user, and it has
similarities with
On Tue, 24 Jul 2007, Ray Lee wrote:
On 7/23/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Ray Lee wrote:
Looking at your past email, you have a 1GB desktop system and your
overnight updatedb run is causing stuff to get swapped out such that
swap prefetch makes it significantly better. This
Ray Lee wrote:
On 7/23/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Also a random day at the desktop, it is quite a broad scope and
pretty well impossible to analyse.
It is pretty broad, but that's also what swap prefetch is targetting.
As for hard to analyze, I'm not sure I agree. One can
From: "Matthew Hawkins" <[EMAIL PROTECTED]>
Date: Wed, 25 Jul 2007 11:26:57 +1000
> On 7/24/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > The other consideration here is, as Nick points out, are the problems which
> > people see this patch solving for them solveable in other, better ways?
> >
On 7/24/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
The other consideration here is, as Nick points out, are the problems which
people see this patch solving for them solveable in other, better ways?
IOW, is this patch fixing up preexisting deficiencies post-facto?
So let me get this straight
However, if we can improve basic page reclaim where it is obviously
lacking, that is always preferable. eg: being a highly speculative
operation, swap prefetch is not great for power efficiency -- but we
still want laptop users to have a good experience as well, right?
Sounds like something
On 7/23/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Ray Lee wrote:
> That said, I'm willing to run my day to day life through both a swap
> prefetch kernel and a normal one. *However*, before I go through all
> the work of instrumenting the damn thing, I'd really like Andrew (or
> Linus) to lay
Ray Lee schrieb:
> I spend a lot of time each day watching my computer fault my
> workingset back in when I switch contexts. I'd rather I didn't have to
> do that. Unfortunately, that's a pretty subjective problem report. For
> whatever it's worth, we have pretty subjective solution reports
>
On Mon, 23 Jul 2007 23:01:41 -0700 "Ray Lee" <[EMAIL PROTECTED]> wrote:
> So, what do I measure to make this an objective problem report?
Ideal would be to find a reproducible-by-others testcase which does what you
believe to be the wrong thing.
> And if
> I do that (and it shows a positive
On 7/23/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
Let it just be noted that Con is not the only one who has expended effort
on this patch. It's been in -mm for nearly two years and it has meant
ongoing effort for me and, to a lesser extent, other MM developers to keep
it alive.
Yes,
On 7/23/07, Andrew Morton [EMAIL PROTECTED] wrote:
Let it just be noted that Con is not the only one who has expended effort
on this patch. It's been in -mm for nearly two years and it has meant
ongoing effort for me and, to a lesser extent, other MM developers to keep
it alive.
nods Yes,
On Mon, 23 Jul 2007 23:01:41 -0700 Ray Lee [EMAIL PROTECTED] wrote:
So, what do I measure to make this an objective problem report?
Ideal would be to find a reproducible-by-others testcase which does what you
believe to be the wrong thing.
And if
I do that (and it shows a positive result),
Ray Lee schrieb:
I spend a lot of time each day watching my computer fault my
workingset back in when I switch contexts. I'd rather I didn't have to
do that. Unfortunately, that's a pretty subjective problem report. For
whatever it's worth, we have pretty subjective solution reports
pointing
On 7/23/07, Nick Piggin [EMAIL PROTECTED] wrote:
Ray Lee wrote:
That said, I'm willing to run my day to day life through both a swap
prefetch kernel and a normal one. *However*, before I go through all
the work of instrumenting the damn thing, I'd really like Andrew (or
Linus) to lay out his
However, if we can improve basic page reclaim where it is obviously
lacking, that is always preferable. eg: being a highly speculative
operation, swap prefetch is not great for power efficiency -- but we
still want laptop users to have a good experience as well, right?
Sounds like something
On 7/24/07, Andrew Morton [EMAIL PROTECTED] wrote:
The other consideration here is, as Nick points out, are the problems which
people see this patch solving for them solveable in other, better ways?
IOW, is this patch fixing up preexisting deficiencies post-facto?
So let me get this straight -
From: Matthew Hawkins [EMAIL PROTECTED]
Date: Wed, 25 Jul 2007 11:26:57 +1000
On 7/24/07, Andrew Morton [EMAIL PROTECTED] wrote:
The other consideration here is, as Nick points out, are the problems which
people see this patch solving for them solveable in other, better ways?
IOW, is this
Ray Lee wrote:
On 7/23/07, Nick Piggin [EMAIL PROTECTED] wrote:
Also a random day at the desktop, it is quite a broad scope and
pretty well impossible to analyse.
It is pretty broad, but that's also what swap prefetch is targetting.
As for hard to analyze, I'm not sure I agree. One can
On Tue, 24 Jul 2007, Ray Lee wrote:
On 7/23/07, Nick Piggin [EMAIL PROTECTED] wrote:
Ray Lee wrote:
Looking at your past email, you have a 1GB desktop system and your
overnight updatedb run is causing stuff to get swapped out such that
swap prefetch makes it significantly better. This
On 07/25/2007 06:06 AM, Nick Piggin wrote:
Ray Lee wrote:
Anyway, my point is that I worry that tuning for an unusual and
infrequent workload (which updatedb certainly is), is the wrong way to
go.
Well it runs every day or so for every desktop Linux user, and it has
similarities with
Rene Herman wrote:
On 07/25/2007 06:06 AM, Nick Piggin wrote:
Ray Lee wrote:
Anyway, my point is that I worry that tuning for an unusual and
infrequent workload (which updatedb certainly is), is the wrong way
to go.
Well it runs every day or so for every desktop Linux user, and it has
On Wed, 25 Jul 2007, Rene Herman wrote:
On 07/25/2007 06:06 AM, Nick Piggin wrote:
Ray Lee wrote:
Anyway, my point is that I worry that tuning for an unusual and
infrequent workload (which updatedb certainly is), is the wrong way to
go.
Well it runs every day or so for every
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 07/25/2007 07:12 AM, [EMAIL PROTECTED] wrote:
On Wed, 25 Jul 2007, 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
On Wed, 25 Jul 2007, Rene Herman wrote:
On 07/25/2007 07:12 AM, [EMAIL PROTECTED] wrote:
On Wed, 25 Jul 2007, 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
On Wed, 25 Jul 2007, Nick Piggin wrote:
Eric St-Laurent wrote:
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
Eric St-Laurent wrote:
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
On Mon, 23 Jul 2007 21:53:38 -0700 "Ray Lee" <[EMAIL PROTECTED]> wrote:
>
> Since this merge period has appeared particularly frazzling for
> Andrew, I've been keeping silent and waiting for him to get to a point
> where there's a breather. I didn't feel it would be polite to request
> yet more
On 7/23/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
Ray Lee wrote:
> That said, I'm willing to run my day to day life through both a swap
> prefetch kernel and a normal one. *However*, before I go through all
> the work of instrumenting the damn thing, I'd really like Andrew (or
> Linus)
Ray Lee wrote:
On 7/23/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
That said, I'm willing to run my day to day life through both a swap
prefetch kernel and a normal one. *However*, before I go through all
the work of instrumenting the damn thing, I'd really like Andrew (or
Linus) to lay out
Ray Lee wrote:
> That said, I'm willing to run my day to day life through both a swap
> prefetch kernel and a normal one. *However*, before I go through all
> the work of instrumenting the damn thing, I'd really like Andrew (or
> Linus) to lay out his acceptance criteria on the feature. Exactly
On 7/23/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Not talking about swap prefetch itself, but everytime I have asked
anyone to instrument or produce some workload where swap prefetch
helps, they never do.
[...]
so for all the people who a whining about merging this and don't want
to actually
Jesper Juhl wrote:
On 10/07/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
On Tuesday 10 July 2007 18:31, Andrew Morton wrote:
> When replying, please rewrite the subject suitably and try to Cc: the
> appropriate developer(s).
~swap prefetch
Nick's only remaining issue which I could remotely
On 10/07/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
On Tuesday 10 July 2007 18:31, Andrew Morton wrote:
> When replying, please rewrite the subject suitably and try to Cc: the
> appropriate developer(s).
~swap prefetch
Nick's only remaining issue which I could remotely identify was to make it
On 10/07/07, Con Kolivas [EMAIL PROTECTED] wrote:
On Tuesday 10 July 2007 18:31, Andrew Morton wrote:
When replying, please rewrite the subject suitably and try to Cc: the
appropriate developer(s).
~swap prefetch
Nick's only remaining issue which I could remotely identify was to make it
Jesper Juhl wrote:
On 10/07/07, Con Kolivas [EMAIL PROTECTED] wrote:
On Tuesday 10 July 2007 18:31, Andrew Morton wrote:
When replying, please rewrite the subject suitably and try to Cc: the
appropriate developer(s).
~swap prefetch
Nick's only remaining issue which I could remotely
On 7/23/07, Nick Piggin [EMAIL PROTECTED] wrote:
Not talking about swap prefetch itself, but everytime I have asked
anyone to instrument or produce some workload where swap prefetch
helps, they never do.
[...]
so for all the people who a whining about merging this and don't want
to actually
Ray Lee wrote:
That said, I'm willing to run my day to day life through both a swap
prefetch kernel and a normal one. *However*, before I go through all
the work of instrumenting the damn thing, I'd really like Andrew (or
Linus) to lay out his acceptance criteria on the feature. Exactly what
Ray Lee wrote:
On 7/23/07, Nick Piggin [EMAIL PROTECTED] wrote:
That said, I'm willing to run my day to day life through both a swap
prefetch kernel and a normal one. *However*, before I go through all
the work of instrumenting the damn thing, I'd really like Andrew (or
Linus) to lay out his
On 7/23/07, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Ray Lee wrote:
That said, I'm willing to run my day to day life through both a swap
prefetch kernel and a normal one. *However*, before I go through all
the work of instrumenting the damn thing, I'd really like Andrew (or
Linus) to lay
On Mon, 23 Jul 2007 21:53:38 -0700 Ray Lee [EMAIL PROTECTED] wrote:
Since this merge period has appeared particularly frazzling for
Andrew, I've been keeping silent and waiting for him to get to a point
where there's a breather. I didn't feel it would be polite to request
yet more work out
On Tuesday 10 July 2007 20:15, Con Kolivas wrote:
> On Tuesday 10 July 2007 18:31, Andrew Morton wrote:
> > When replying, please rewrite the subject suitably and try to Cc: the
> > appropriate developer(s).
>
> ~swap prefetch
>
> Nick's only remaining issue which I could remotely identify was to
On Tuesday 10 July 2007 20:15, Con Kolivas wrote:
On Tuesday 10 July 2007 18:31, Andrew Morton wrote:
When replying, please rewrite the subject suitably and try to Cc: the
appropriate developer(s).
~swap prefetch
Nick's only remaining issue which I could remotely identify was to make it
On Fri, Jul 20, 2007 at 01:27:26PM +1000, Rusty Russell wrote:
> On Thu, 2007-07-19 at 19:27 +0200, Christoph Hellwig wrote:
> > The version that just got into mainline still has the __put_task_struct
> > export despite not needing it anymore. Care to fix this up?
>
> No, it got patched in then
On Fri, Jul 20, 2007 at 01:27:26PM +1000, Rusty Russell wrote:
On Thu, 2007-07-19 at 19:27 +0200, Christoph Hellwig wrote:
The version that just got into mainline still has the __put_task_struct
export despite not needing it anymore. Care to fix this up?
No, it got patched in then
On Thu, 2007-07-19 at 19:27 +0200, Christoph Hellwig wrote:
> The version that just got into mainline still has the __put_task_struct
> export despite not needing it anymore. Care to fix this up?
No, it got patched in then immediately patched out again. Andrew
mis-mixed my patches, but there
On Thu, Jul 12, 2007 at 02:52:23PM +1000, Rusty Russell wrote:
> This is solely for the wakeup: you don't wake an mm 8)
>
> The mm reference is held as well under the big lguest_mutex (mm gets
> destroyed before files get closed, so we definitely do need to hold a
> reference).
>
> I just
On Thu, Jul 12, 2007 at 02:52:23PM +1000, Rusty Russell wrote:
This is solely for the wakeup: you don't wake an mm 8)
The mm reference is held as well under the big lguest_mutex (mm gets
destroyed before files get closed, so we definitely do need to hold a
reference).
I just completed
On Thu, 2007-07-19 at 19:27 +0200, Christoph Hellwig wrote:
The version that just got into mainline still has the __put_task_struct
export despite not needing it anymore. Care to fix this up?
No, it got patched in then immediately patched out again. Andrew
mis-mixed my patches, but there have
On Tue, 10 Jul 2007 01:31:52 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:
> unprivileged-mounts-add-user-mounts-to-the-kernel.patch
> unprivileged-mounts-allow-unprivileged-umount.patch
> unprivileged-mounts-account-user-mounts.patch
>
On Tue, 10 Jul 2007 01:31:52 -0700 Andrew Morton [EMAIL PROTECTED] wrote:
unprivileged-mounts-add-user-mounts-to-the-kernel.patch
unprivileged-mounts-allow-unprivileged-umount.patch
unprivileged-mounts-account-user-mounts.patch
unprivileged-mounts-propagate-error-values-from-clone_mnt.patch
On Jul 14 2007 01:09, Tilman Schmidt wrote:
>Am 13.07.2007 11:46 schrieb Jan Engelhardt:
>> On Jul 10 2007 01:31, Andrew Morton wrote:
>>
>>> use-menuconfig-objects-isdn-config_isdn_i4l.patch
>>>
>>> tilman didn't like it - might drop
>>
>> Or replace by his suggestion patch (
On Jul 14 2007 01:09, Tilman Schmidt wrote:
Am 13.07.2007 11:46 schrieb Jan Engelhardt:
On Jul 10 2007 01:31, Andrew Morton wrote:
use-menuconfig-objects-isdn-config_isdn_i4l.patch
tilman didn't like it - might drop
Or replace by his suggestion patch ( http://lkml.org/lkml/2007/5/31/222
On Fri, 2007-07-13 at 19:23 +0200, Roman Zippel wrote:
> Hi,
>
> On Fri, 13 Jul 2007, Mike Galbraith wrote:
>
> > > The new scheduler does _a_lot_ of heavy 64 bit calculations without any
> > > attempt to scale that down a little...
> >
> > See prio_to_weight[], prio_to_wmult[] and
Am 13.07.2007 11:46 schrieb Jan Engelhardt:
> On Jul 10 2007 01:31, Andrew Morton wrote:
>
>> use-menuconfig-objects-isdn-config_isdn_i4l.patch
>>
>> tilman didn't like it - might drop
>
> Or replace by his suggestion patch ( http://lkml.org/lkml/2007/5/31/222 )
That posting was just a change
Hi,
On Fri, 13 Jul 2007, Mike Galbraith wrote:
> > The new scheduler does _a_lot_ of heavy 64 bit calculations without any
> > attempt to scale that down a little...
>
> See prio_to_weight[], prio_to_wmult[] and sysctl_sched_stat_granularity.
> Perhaps more can be done, but "without any
On Jul 10 2007 01:31, Andrew Morton wrote:
>use-menuconfig-objects-isdn-config_isdn_i4l.patch
>
> tilman didn't like it - might drop
Or replace by his suggestion patch ( http://lkml.org/lkml/2007/5/31/222 )
Jan
--
-
To unsubscribe from this list: send the line "unsubscribe
On Jul 10 2007 01:31, Andrew Morton wrote:
use-menuconfig-objects-isdn-config_isdn_i4l.patch
tilman didn't like it - might drop
Or replace by his suggestion patch ( http://lkml.org/lkml/2007/5/31/222 )
Jan
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
Hi,
On Fri, 13 Jul 2007, Mike Galbraith wrote:
The new scheduler does _a_lot_ of heavy 64 bit calculations without any
attempt to scale that down a little...
See prio_to_weight[], prio_to_wmult[] and sysctl_sched_stat_granularity.
Perhaps more can be done, but without any attempt...
Am 13.07.2007 11:46 schrieb Jan Engelhardt:
On Jul 10 2007 01:31, Andrew Morton wrote:
use-menuconfig-objects-isdn-config_isdn_i4l.patch
tilman didn't like it - might drop
Or replace by his suggestion patch ( http://lkml.org/lkml/2007/5/31/222 )
That posting was just a change proposal
On Fri, 2007-07-13 at 19:23 +0200, Roman Zippel wrote:
Hi,
On Fri, 13 Jul 2007, Mike Galbraith wrote:
The new scheduler does _a_lot_ of heavy 64 bit calculations without any
attempt to scale that down a little...
See prio_to_weight[], prio_to_wmult[] and
On Fri, 2007-07-13 at 04:23 +0200, Roman Zippel wrote:
> Hi,
Hi,
> The new scheduler does _a_lot_ of heavy 64 bit calculations without any
> attempt to scale that down a little...
See prio_to_weight[], prio_to_wmult[] and sysctl_sched_stat_granularity.
Perhaps more can be done, but "without
On Fri, 13 Jul 2007 04:23:43 +0200 (CEST) Roman Zippel <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> On Wed, 11 Jul 2007, Linus Torvalds wrote:
>
> > Sure, bugs happen, but code that everybody runs the same generally doesn't
> > break. So a CPU scheduler doesn't worry me all that much. CPU schedulers
Hi,
On Wed, 11 Jul 2007, Linus Torvalds wrote:
> Sure, bugs happen, but code that everybody runs the same generally doesn't
> break. So a CPU scheduler doesn't worry me all that much. CPU schedulers
> are "easy".
A little more advance warning wouldn't have hurt though.
The new scheduler does
On Thu, 2007-07-12 at 14:10 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > Remove export of __put_task_struct, and usage in lguest
> >
> > lguest takes a reference count of tasks for two reasons. The first is
> > bogus: the /dev/lguest close callback will be called before the task
> > is
On Thu, Jul 12, 2007 at 12:50:19AM +0200, Thomas Gleixner wrote:
> Linus,
>
> On Wed, 2007-07-11 at 15:20 -0700, Linus Torvalds wrote:
> > For example, we can make sure that the code in question that actually
> > touches the hardware stays exactly the same, and then just move the
> > interfaces
On Thu, Jul 12, 2007 at 12:33:43PM -0700, Christoph Lameter wrote:
> On Wed, 11 Jul 2007, Andi Kleen wrote:
>
> > These all need re-review:
> >
> > > i386-add-support-for-picopower-irq-router.patch
> > > make-arch-i386-kernel-setupcremapped_pgdat_init-static.patch
> > >
On Wed, 11 Jul 2007, Andi Kleen wrote:
> These all need re-review:
>
> > i386-add-support-for-picopower-irq-router.patch
> > make-arch-i386-kernel-setupcremapped_pgdat_init-static.patch
> > arch-i386-kernel-i8253c-should-include-asm-timerh.patch
> >
* Linus Torvalds "Wed, 11 Jul 2007 15:09:28 -0700 (PDT)"
>
> On Wed, 11 Jul 2007, Andrea Arcangeli wrote:
>>
>> I'm going to change topic big time because your sentence above
>> perfectly applies to the O(1) scheduler too.
>
> I disagree to a large degree.
>
> We almost never have problems with
301 - 400 of 707 matches
Mail list logo
