On Friday 07 December 2007 22:17, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > ah, printk_clock() still uses sched_clock(), not jiffies. So it's
> > > not the jiffies counter that goes back and forth, it's sched_clock()
> > > - so
On Friday 07 December 2007 19:45, Ingo Molnar wrote:
> * Stefano Brivio <[EMAIL PROTECTED]> wrote:
> > This patch fixes a regression introduced by:
> >
> > commit bb29ab26863c022743143f27956cc0ca362f258c
> > Author: Ingo Molnar <[EMAIL PROTECTED]>
> > Date: Mon Jul 9 18:51:59 2007 +0200
> >
> >
On Friday 07 December 2007 19:45, Ingo Molnar wrote:
* Stefano Brivio [EMAIL PROTECTED] wrote:
This patch fixes a regression introduced by:
commit bb29ab26863c022743143f27956cc0ca362f258c
Author: Ingo Molnar [EMAIL PROTECTED]
Date: Mon Jul 9 18:51:59 2007 +0200
This caused the
On Saturday 08 December 2007 11:50, Nick Piggin wrote:
I guess your patch is fairly complex but it should work
I should also add that although complex, it should have a
much smaller TSC delta window in which the wrong scaling
factor can get applied to it (I guess it is about as good
as you can
On Friday 07 December 2007 22:17, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
ah, printk_clock() still uses sched_clock(), not jiffies. So it's
not the jiffies counter that goes back and forth, it's sched_clock()
- so this is a printk timestamps anomaly, not related
On Saturday 08 December 2007 03:48, Nick Piggin wrote:
On Friday 07 December 2007 22:17, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
ah, printk_clock() still uses sched_clock(), not jiffies. So it's
not the jiffies counter that goes back and forth, it's sched_clock
On Friday 07 December 2007 12:19, Stefano Brivio wrote:
> This patch fixes a regression introduced by:
>
> commit bb29ab26863c022743143f27956cc0ca362f258c
> Author: Ingo Molnar <[EMAIL PROTECTED]>
> Date: Mon Jul 9 18:51:59 2007 +0200
>
> This caused the jiffies counter to leap back and forth on
On Thu, Dec 06, 2007 at 10:17:39PM -0600, Rob Landley wrote:
> On Thursday 06 December 2007 21:22:25 Jared Hulbert wrote:
> > > > I have'nt looked at it yet. I do appreciate it, I think it might
> > > > broaden the user-base of this feature which is up to now s390 only due
> > > > to the fact that
On Thursday 06 December 2007 20:33, Li Zefan wrote:
> The casting is safe only when the list_head member is the
> first member of the structure.
Even so, I don't think too safe :) It might technically work,
but it could break more easily.
So even if you find places where list_head is the first
On Thu, Dec 06, 2007 at 10:59:02AM +0100, Carsten Otte wrote:
> Nick Piggin wrote:
> >After my patch, we can do XIP in a hardsect size < PAGE_SIZE block
> >device -- this seems to be a fine thing to do at least for the
> >ramdisk code. Would this situation be problema
On Thu, Dec 06, 2007 at 09:43:27AM +0100, Carsten Otte wrote:
> Nick Piggin wrote:
> >>Xip does only work, if both do match PAGE_SIZE because it
> >>does'nt support multiple calls to direct_access in the get_xip_page
> >>address space operation. Thu
On Thu, Dec 06, 2007 at 09:43:27AM +0100, Carsten Otte wrote:
Nick Piggin wrote:
Xip does only work, if both do match PAGE_SIZE because it
does'nt support multiple calls to direct_access in the get_xip_page
address space operation. Thus we check both here, actually this was
changed from
On Thu, Dec 06, 2007 at 10:59:02AM +0100, Carsten Otte wrote:
Nick Piggin wrote:
After my patch, we can do XIP in a hardsect size PAGE_SIZE block
device -- this seems to be a fine thing to do at least for the
ramdisk code. Would this situation be problematic for existing drivers,
and if so
On Thursday 06 December 2007 20:33, Li Zefan wrote:
The casting is safe only when the list_head member is the
first member of the structure.
Even so, I don't think too safe :) It might technically work,
but it could break more easily.
So even if you find places where list_head is the first
On Thu, Dec 06, 2007 at 10:17:39PM -0600, Rob Landley wrote:
On Thursday 06 December 2007 21:22:25 Jared Hulbert wrote:
I have'nt looked at it yet. I do appreciate it, I think it might
broaden the user-base of this feature which is up to now s390 only due
to the fact that the flash
On Friday 07 December 2007 12:19, Stefano Brivio wrote:
This patch fixes a regression introduced by:
commit bb29ab26863c022743143f27956cc0ca362f258c
Author: Ingo Molnar [EMAIL PROTECTED]
Date: Mon Jul 9 18:51:59 2007 +0200
This caused the jiffies counter to leap back and forth on cpufreq
On Wed, Dec 05, 2007 at 08:39:25AM -0800, Pete Zaitcev wrote:
> On Wed, 05 Dec 2007 18:15:59 +1100, [EMAIL PROTECTED] wrote:
>
> > Convert USB mon driver from nopage to fault.
>
> > if (offset >= rp->b_size)
> > - return NOPAGE_SIGBUS;
> > + return VM_FAULT_SIGBUS;
> >
On Wed, Dec 05, 2007 at 02:15:35PM +0100, Stefan Richter wrote:
> > [EMAIL PROTECTED] wrote:
> >> @@ -275,7 +270,7 @@ int dma_region_mmap(struct dma_region *d
> >>if (!dma->kvirt)
> >>return -EINVAL;
> >>
> >> - /* must be page-aligned */
> >> + /* must be page-aligned (XXX:
he 1394 drivers and I'm too
> lazy to figure this out myself, so I ask: What would trip the .fault
> handler? Would be good if I could runtime-test it.
mmap()ing a device file for that driver, and accessing the memory.
> > Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
&
On Wed, Dec 05, 2007 at 04:43:16PM +0100, Carsten Otte wrote:
> Nick Piggin wrote:
> >Am I missing something here? I wonder how s390 works without this change?
> >
> >--
> >ext2 should not worry about checking sb->s_blocksize for XIP before the
> >sb's blocks
On Wed, Dec 05, 2007 at 02:47:00PM -0800, Andrew Morton wrote:
> On Wed, 05 Dec 2007 18:16:04 +1100
> [EMAIL PROTECTED] wrote:
>
> > Nothing in the tree uses nopage any more. Remove support for it in the
> > core mm code and documentation (and a few stray references to it in
> > comments).
>
>
On Wed, Dec 05, 2007 at 11:25:00AM +0100, Hans-Jürgen Koch wrote:
> Am Wed, 5 Dec 2007 11:10:42 +0100
> schrieb Nick Piggin <[EMAIL PROTECTED]>:
>
> > On Wed, Dec 05, 2007 at 11:04:08AM +0100, Hans-Jürgen Koch wrote:
> > > Am Wed, 05 Dec 2007 18:15:51 +1100
the earliest deadline in the hope that we avoid a deadline
> expiry later on.
>
> Signed-off-by: Aaron Carroll <[EMAIL PROTECTED]>
I think this seems reasonable. What's deadline doing in this case?
They should probably be kept in synch where possible...
Acked-by: Nick Piggin <[EMA
On Wed, Dec 05, 2007 at 09:06:50PM +1100, Aaron Carroll wrote:
> Two comments refer to deadlines applying to reads only. This is
> not the case.
>
> Signed-off-by: Aaron Carroll <[EMAIL PROTECTED]>
Acked-by: Nick Piggin <[EMAIL PROTECTED]>
> ---
> block/as-io
On Wed, Dec 05, 2007 at 11:04:08AM +0100, Hans-Jürgen Koch wrote:
> Am Wed, 05 Dec 2007 18:15:51 +1100
> schrieb [EMAIL PROTECTED]:
>
> > Convert uio from nopage to fault.
> >
> > Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
> > Cc: [EMAIL PROTECTED]
On Wed, Dec 05, 2007 at 09:05:06AM +, Dave Airlie wrote:
>
> > Convert drm from nopage to fault.
> > Remove redundant vma range checks.
>
> Hi Nick,
>
> can you rebase against the -mm tree? or are you pushing this for before
> then? if so can you supply me a patch against -mm?
I'm not
On Wed, Dec 05, 2007 at 09:05:06AM +, Dave Airlie wrote:
Convert drm from nopage to fault.
Remove redundant vma range checks.
Hi Nick,
can you rebase against the -mm tree? or are you pushing this for before
then? if so can you supply me a patch against -mm?
I'm not sure where I
in the hope that we avoid a deadline
expiry later on.
Signed-off-by: Aaron Carroll [EMAIL PROTECTED]
I think this seems reasonable. What's deadline doing in this case?
They should probably be kept in synch where possible...
Acked-by: Nick Piggin [EMAIL PROTECTED]
---
block/as-iosched.c
On Wed, Dec 05, 2007 at 11:04:08AM +0100, Hans-Jürgen Koch wrote:
Am Wed, 05 Dec 2007 18:15:51 +1100
schrieb [EMAIL PROTECTED]:
Convert uio from nopage to fault.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Hi Nick,
could you please add me to Cc: for UIO
On Wed, Dec 05, 2007 at 02:47:00PM -0800, Andrew Morton wrote:
On Wed, 05 Dec 2007 18:16:04 +1100
[EMAIL PROTECTED] wrote:
Nothing in the tree uses nopage any more. Remove support for it in the
core mm code and documentation (and a few stray references to it in
comments).
I'll duck
On Wed, Dec 05, 2007 at 04:43:16PM +0100, Carsten Otte wrote:
Nick Piggin wrote:
Am I missing something here? I wonder how s390 works without this change?
--
ext2 should not worry about checking sb-s_blocksize for XIP before the
sb's blocksize actually gets set.
Signed-off-by: Nick
On Wed, Dec 05, 2007 at 09:06:50PM +1100, Aaron Carroll wrote:
Two comments refer to deadlines applying to reads only. This is
not the case.
Signed-off-by: Aaron Carroll [EMAIL PROTECTED]
Acked-by: Nick Piggin [EMAIL PROTECTED]
---
block/as-iosched.c |4 ++--
1 files changed, 2
On Wed, Dec 05, 2007 at 11:25:00AM +0100, Hans-Jürgen Koch wrote:
Am Wed, 5 Dec 2007 11:10:42 +0100
schrieb Nick Piggin [EMAIL PROTECTED]:
On Wed, Dec 05, 2007 at 11:04:08AM +0100, Hans-Jürgen Koch wrote:
Am Wed, 05 Dec 2007 18:15:51 +1100
schrieb [EMAIL PROTECTED]:
Convert uio
to figure this out myself, so I ask: What would trip the .fault
handler? Would be good if I could runtime-test it.
mmap()ing a device file for that driver, and accessing the memory.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
It's an obscure and unimportant detail
On Wed, Dec 05, 2007 at 02:15:35PM +0100, Stefan Richter wrote:
[EMAIL PROTECTED] wrote:
@@ -275,7 +270,7 @@ int dma_region_mmap(struct dma_region *d
if (!dma-kvirt)
return -EINVAL;
- /* must be page-aligned */
+ /* must be page-aligned (XXX: comment is wrong, we
On Wed, Dec 05, 2007 at 08:39:25AM -0800, Pete Zaitcev wrote:
On Wed, 05 Dec 2007 18:15:59 +1100, [EMAIL PROTECTED] wrote:
Convert USB mon driver from nopage to fault.
if (offset = rp-b_size)
- return NOPAGE_SIGBUS;
+ return VM_FAULT_SIGBUS;
chunk_idx =
On Tue, Dec 04, 2007 at 12:06:23PM +, Duane Griffin wrote:
> On 04/12/2007, Nick Piggin <[EMAIL PROTECTED]> wrote:
> > + gfp_flags = GFP_NOIO | __GFP_ZERO;
> > +#ifndef CONFIG_BLK_DEV_XIP
> > + gfp_flags |= __GFP_HIGHMEM;
> > +#endif
>
On Tue, Dec 04, 2007 at 12:35:49PM +0100, Nick Piggin wrote:
> On Tue, Dec 04, 2007 at 03:26:20AM -0800, Andrew Morton wrote:
> > On Tue, 4 Dec 2007 12:21:00 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> > > + *
> > > + * Cannot support XIP a
On Tue, Dec 04, 2007 at 03:26:20AM -0800, Andrew Morton wrote:
> On Tue, 4 Dec 2007 12:21:00 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > +*
> > +* Cannot support XIP and highmem, because our ->direct_access
> > +* routine for XIP must return
Am I missing something here? I wonder how s390 works without this change?
--
ext2 should not worry about checking sb->s_blocksize for XIP before the
sb's blocksize actually gets set.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/fs/ext
On Tue, Dec 04, 2007 at 11:10:09AM +0100, Nick Piggin wrote:
> >
> > This is just an idea, I dont know if it is worth the trouble, but have you
> > though about implementing direct_access for brd? That would allow
> > execute-in-place (xip) on brd eliminating the extra co
On Tue, Dec 04, 2007 at 10:54:51AM +0100, Christian Borntraeger wrote:
> Am Dienstag, 4. Dezember 2007 schrieb Nick Piggin:
> [...]
> > There is one slight downside -- direct block device access and filesystem
> > metadata access goes through an extra copy and gets stored in RAM
On Tue, Dec 04, 2007 at 01:55:17AM -0600, Rob Landley wrote:
> On Monday 03 December 2007 22:26:28 Nick Piggin wrote:
> > There is one slight downside -- direct block device access and filesystem
> > metadata access goes through an extra copy and gets stored in RAM twi
On Tue, Dec 04, 2007 at 01:55:17AM -0600, Rob Landley wrote:
On Monday 03 December 2007 22:26:28 Nick Piggin wrote:
There is one slight downside -- direct block device access and filesystem
metadata access goes through an extra copy and gets stored in RAM twice.
However, this downside
On Tue, Dec 04, 2007 at 10:54:51AM +0100, Christian Borntraeger wrote:
Am Dienstag, 4. Dezember 2007 schrieb Nick Piggin:
[...]
There is one slight downside -- direct block device access and filesystem
metadata access goes through an extra copy and gets stored in RAM twice.
However
On Tue, Dec 04, 2007 at 11:10:09AM +0100, Nick Piggin wrote:
This is just an idea, I dont know if it is worth the trouble, but have you
though about implementing direct_access for brd? That would allow
execute-in-place (xip) on brd eliminating the extra copy.
Actually that's a pretty
Am I missing something here? I wonder how s390 works without this change?
--
ext2 should not worry about checking sb-s_blocksize for XIP before the
sb's blocksize actually gets set.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/fs/ext2/super.c
On Tue, Dec 04, 2007 at 03:26:20AM -0800, Andrew Morton wrote:
On Tue, 4 Dec 2007 12:21:00 +0100 Nick Piggin [EMAIL PROTECTED] wrote:
+*
+* Cannot support XIP and highmem, because our -direct_access
+* routine for XIP must return memory that is always addressable
On Tue, Dec 04, 2007 at 12:35:49PM +0100, Nick Piggin wrote:
On Tue, Dec 04, 2007 at 03:26:20AM -0800, Andrew Morton wrote:
On Tue, 4 Dec 2007 12:21:00 +0100 Nick Piggin [EMAIL PROTECTED] wrote:
+ *
+ * Cannot support XIP and highmem, because our -direct_access
+ * routine
On Tue, Dec 04, 2007 at 12:06:23PM +, Duane Griffin wrote:
On 04/12/2007, Nick Piggin [EMAIL PROTECTED] wrote:
+ gfp_flags = GFP_NOIO | __GFP_ZERO;
+#ifndef CONFIG_BLK_DEV_XIP
+ gfp_flags |= __GFP_HIGHMEM;
+#endif
page = alloc_page(GFP_NOIO | __GFP_HIGHMEM
On Tue, Dec 04, 2007 at 08:01:31AM +0100, Nick Piggin wrote:
> Thanks for the review, I'll post an incremental patch in a sec.
Index: linux-2.6/drivers/block/brd.c
===
--- linux-2.6.orig/drivers/block/brd.c
+++ linux-2.6/driv
On Mon, Dec 03, 2007 at 10:29:03PM -0800, Andrew Morton wrote:
> On Tue, 4 Dec 2007 05:26:28 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> > There is one slight downside -- direct block device access and filesystem
> > metadata access goes through an extra copy a
it is no longer part of the
ramdisk code).
- Boot / load time flexible ramdisk size, which could easily be extended
to a per-ramdisk runtime changeable size (eg. with an ioctl).
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
MAINTAINERS|5
drivers/block/Kconfig | 12 -
d
On Tuesday 04 December 2007 11:30, David Schwartz wrote:
> Perhaps it might be possible to scan for the task at the same static
> priority level that is ready-to-run but last in line among other
> ready-to-run tasks and put it after that task?
Nice level versus posix static priority level debate
On Monday 03 December 2007 22:37, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > given how poorly sched_yield() is/was defined the only "compatible"
> > > solution would be to go back to the old yield code.
> >
> &g
On Tuesday 04 December 2007 09:33, Ingo Molnar wrote:
> * Mark Lord <[EMAIL PROTECTED]> wrote:
> >> heh, thanks :) For which workload does it make the biggest difference
> >> for you? (and compared to what other scheduler you used before?
> >> 2.6.22?)
> >
> > ..
> >
> > Heh.. I'm just a very
On Mon, Dec 03, 2007 at 06:01:40PM +0530, Supriya Kannery wrote:
> Nick Piggin wrote:
> >On Thu, Nov 29, 2007 at 02:45:23PM -0500, Chuck Ebbert wrote:
> >
> >>Original report: https://bugzilla.redhat.com/show_bug.cgi?id=404201
> >>
> >>The test case belo
On Monday 03 December 2007 21:33, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > > I was just talking about the default because I didn't know the
> > > > reason for the way it was set -- now that I do, we should talk
> > > > about
On Monday 03 December 2007 20:57, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > as far as desktop apps such as firefox goes, the exact opposite is
> > > true. We had two choices basically: either a "more agressive" yield
> > > th
On Monday 03 December 2007 19:45, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > On Friday 30 November 2007 21:08, Ingo Molnar wrote:
> > > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > > Haven't we been asking JVMs to use futexes or
On Monday 03 December 2007 19:45, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
On Friday 30 November 2007 21:08, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
Haven't we been asking JVMs to use futexes or posix locking for years
and years now? [...]
i'm
On Monday 03 December 2007 20:57, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
as far as desktop apps such as firefox goes, the exact opposite is
true. We had two choices basically: either a more agressive yield
than before or a less agressive yield. Desktop apps were
On Monday 03 December 2007 21:33, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
I was just talking about the default because I didn't know the
reason for the way it was set -- now that I do, we should talk
about trying to improve the actual code so we don't need 2
On Mon, Dec 03, 2007 at 06:01:40PM +0530, Supriya Kannery wrote:
Nick Piggin wrote:
On Thu, Nov 29, 2007 at 02:45:23PM -0500, Chuck Ebbert wrote:
Original report: https://bugzilla.redhat.com/show_bug.cgi?id=404201
The test case below, taken from the LTP test code, prints -1 (as
expected
On Tuesday 04 December 2007 09:33, Ingo Molnar wrote:
* Mark Lord [EMAIL PROTECTED] wrote:
heh, thanks :) For which workload does it make the biggest difference
for you? (and compared to what other scheduler you used before?
2.6.22?)
..
Heh.. I'm just a very unsophisticated desktop
On Monday 03 December 2007 22:37, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
given how poorly sched_yield() is/was defined the only compatible
solution would be to go back to the old yield code.
While it is technically allowed to do anything with SCHED_OTHER class
On Tuesday 04 December 2007 11:30, David Schwartz wrote:
Perhaps it might be possible to scan for the task at the same static
priority level that is ready-to-run but last in line among other
ready-to-run tasks and put it after that task?
Nice level versus posix static priority level debate
it is no longer part of the
ramdisk code).
- Boot / load time flexible ramdisk size, which could easily be extended
to a per-ramdisk runtime changeable size (eg. with an ioctl).
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
MAINTAINERS|5
drivers/block/Kconfig | 12 -
drivers
On Mon, Dec 03, 2007 at 10:29:03PM -0800, Andrew Morton wrote:
On Tue, 4 Dec 2007 05:26:28 +0100 Nick Piggin [EMAIL PROTECTED] wrote:
There is one slight downside -- direct block device access and filesystem
metadata access goes through an extra copy and gets stored in RAM twice.
However
On Tue, Dec 04, 2007 at 08:01:31AM +0100, Nick Piggin wrote:
Thanks for the review, I'll post an incremental patch in a sec.
Index: linux-2.6/drivers/block/brd.c
===
--- linux-2.6.orig/drivers/block/brd.c
+++ linux-2.6/drivers
On Friday 30 November 2007 21:08, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Haven't we been asking JVMs to use futexes or posix locking for years
> > and years now? [...]
>
> i'm curious, with what JVM was it tested and where's the source s
On Friday 30 November 2007 21:08, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
Haven't we been asking JVMs to use futexes or posix locking for years
and years now? [...]
i'm curious, with what JVM was it tested and where's the source so i can
fix their locking for them? Can
On Friday 30 November 2007 14:15, Zhang, Yanmin wrote:
> On Fri, 2007-11-30 at 13:46 +1100, Nick Piggin wrote:
> > On Wednesday 28 November 2007 09:57, Arjan van de Ven wrote:
> > > sounds like a bad idea; volanomark (well, technically the jvm behind
> > > it) is abusin
On Friday 30 November 2007 13:51, Arjan van de Ven wrote:
> On Fri, 30 Nov 2007 13:46:22 +1100
>
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > Todays kernel has a different behavior somewhat (and before people
> > > scream "regression"; sc
On Wednesday 28 November 2007 09:57, Arjan van de Ven wrote:
> On Tue, 27 Nov 2007 17:33:05 +0800
>
> "Zhang, Yanmin" <[EMAIL PROTECTED]> wrote:
> > If echo "1">/proc/sys/kernel/sched_compat_yield before starting
> > volanoMark testing, the result is very good with kernel 2.6.24-rc3 on
> > my
until the merge window, I'd like to
> set aside some time (from my other work items) to work on the memory
> controller, fix review comments and defects.
>
> In the past, we've received several useful comments from Rik Van Riel,
> Lee Schermerhorn, Peter Zijlstra, Hugh Dickins, Nick
On Thu, Nov 29, 2007 at 02:45:23PM -0500, Chuck Ebbert wrote:
> Original report: https://bugzilla.redhat.com/show_bug.cgi?id=404201
>
> The test case below, taken from the LTP test code, prints -1 (as
> expected) on 2.6.22 and 0 on 2.6.23. It tries to remap an out-of-range
> page. Proposed patch
On Thu, Nov 29, 2007 at 02:45:23PM -0500, Chuck Ebbert wrote:
Original report: https://bugzilla.redhat.com/show_bug.cgi?id=404201
The test case below, taken from the LTP test code, prints -1 (as
expected) on 2.6.22 and 0 on 2.6.23. It tries to remap an out-of-range
page. Proposed patch
On Wednesday 28 November 2007 09:57, Arjan van de Ven wrote:
On Tue, 27 Nov 2007 17:33:05 +0800
Zhang, Yanmin [EMAIL PROTECTED] wrote:
If echo 1/proc/sys/kernel/sched_compat_yield before starting
volanoMark testing, the result is very good with kernel 2.6.24-rc3 on
my 16-core tigerton.
On Friday 30 November 2007 14:15, Zhang, Yanmin wrote:
On Fri, 2007-11-30 at 13:46 +1100, Nick Piggin wrote:
On Wednesday 28 November 2007 09:57, Arjan van de Ven wrote:
sounds like a bad idea; volanomark (well, technically the jvm behind
it) is abusing sched_yield() by assuming it does
On Friday 30 November 2007 13:51, Arjan van de Ven wrote:
On Fri, 30 Nov 2007 13:46:22 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
Todays kernel has a different behavior somewhat (and before people
scream regression; sched_yield() behavior isn't really specified
and doesn't make any
window, I'd like to
set aside some time (from my other work items) to work on the memory
controller, fix review comments and defects.
In the past, we've received several useful comments from Rik Van Riel,
Lee Schermerhorn, Peter Zijlstra, Hugh Dickins, Nick Piggin, Paul Menage
and code
tag lookup API as well...
> Furthermore, the existing radix_tree_gang_lookup() can use this same
> function if we define a RADIX_TREE_MAX_INDEX value so the search is not
> limited by the last_index.
Nit: should just define it to be ULONG_MAX.
>
> Signed-off-by: Dave Chinner &
On Saturday 24 November 2007 00:09, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Ahh, hate to get off topic, but let's not perpetuate this myth. It
> > wasn't Con, or CFS, or anything that showed fairness is some great new
> > idea. Actually I was
On Saturday 24 November 2007 00:09, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
Ahh, hate to get off topic, but let's not perpetuate this myth. It
wasn't Con, or CFS, or anything that showed fairness is some great new
idea. Actually I was arguing for fairness first, against
use this same
function if we define a RADIX_TREE_MAX_INDEX value so the search is not
limited by the last_index.
Nit: should just define it to be ULONG_MAX.
Signed-off-by: Dave Chinner [EMAIL PROTECTED]
Otherwise, Acked-by: Nick Piggin [EMAIL PROTECTED]
-
To unsubscribe from this list: send
On Wednesday 21 November 2007 06:07, Arjan van de Ven wrote:
> On Wed, 21 Nov 2007 02:43:46 +1100
> > Of course it is, if you want to effectively use your resources.
> > Imagine if the task balancer only polled once every 10s.
>
> but unlike the task balancer, moving an irq is really expensive.
>
On Wednesday 21 November 2007 06:07, Arjan van de Ven wrote:
On Wed, 21 Nov 2007 02:43:46 +1100
Of course it is, if you want to effectively use your resources.
Imagine if the task balancer only polled once every 10s.
but unlike the task balancer, moving an irq is really expensive.
(at
On Wednesday 21 November 2007 01:47, Arjan van de Ven wrote:
> On Tue, 20 Nov 2007 18:37:39 +1100
>
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > actually no. IRQ balancing is not a "fast" decision; every time
> > > you
> >
> > I di
On Tuesday 20 November 2007 20:09, Ian Kumlien wrote:
> On tis, 2007-11-20 at 15:13 +1100, Nick Piggin wrote:
> > It's also used up all your 2.5GB of swap. The output of your `free` shows
> > a fair bit of disk cache there, but it also shows a lot of swap free,
> > which
On Tuesday 20 November 2007 18:26, Nick Piggin wrote:
> On Tuesday 20 November 2007 16:46, Ingo Molnar wrote:
> > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > Unfortunately, we don't show NR_ANON_PAGES in these stats, [...]
> >
> > sidenote: t
On Tuesday 20 November 2007 18:26, Nick Piggin wrote:
On Tuesday 20 November 2007 16:46, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
Unfortunately, we don't show NR_ANON_PAGES in these stats, [...]
sidenote: the way i combat these missing pieces of instrumentation
On Tuesday 20 November 2007 20:09, Ian Kumlien wrote:
On tis, 2007-11-20 at 15:13 +1100, Nick Piggin wrote:
It's also used up all your 2.5GB of swap. The output of your `free` shows
a fair bit of disk cache there, but it also shows a lot of swap free,
which isn't the case at oom-time
On Wednesday 21 November 2007 01:47, Arjan van de Ven wrote:
On Tue, 20 Nov 2007 18:37:39 +1100
Nick Piggin [EMAIL PROTECTED] wrote:
actually no. IRQ balancing is not a fast decision; every time
you
I didn't say anything of the sort. But IRQ load could still fluctuate
a lot more
On Tuesday 20 November 2007 16:37, Arjan van de Ven wrote:
> On Tue, 20 Nov 2007 15:17:15 +1100
> > For that matter, I'd like to know why it has been decided that the
> > best place for IRQ balancing is in userspace. It should be in kernel
> > IMO, and it would probably allow better power saving,
On Tuesday 20 November 2007 16:46, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Unfortunately, we don't show NR_ANON_PAGES in these stats, [...]
>
> sidenote: the way i combat these missing pieces of instrumentation in
> the scheduler is to add the
On Tuesday 20 November 2007 15:37, Adrian Bunk wrote:
> On Tue, Nov 20, 2007 at 05:29:29AM +0100, Willy Tarreau wrote:
> > Agreed. When userspace has something to do with the way IRQs are
> > delivered, it's going to smell as bad as micro-kernels...
>
> The next step to a micro-kernel would then
Don't know who maintains vt.c, but Antonino's name comes up regularly ;)
--
vt is missing a memory barrier to close the critical section. Use a real
spinlock for this.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/drivers/cha
On Tuesday 20 November 2007 15:12, Mark Lord wrote:
> On 32-bit x86, we have CONFIG_IRQBALANCE available,
> but not on 64-bit x86. Why not?
>
> I ask, because this feature seems almost essential to obtaining
> reasonable latencies during heavy I/O with fast devices.
>
> My 32-bit Core2Duo MythTV
On Tuesday 20 November 2007 11:59, Ian Kumlien wrote:
> Hi,
>
> I have had this before and sent a mail about it.
>
> It seems like the diskcache is still in use and is never shrunk. This
> happened with a odd load though, trackerd started indexing a bit late
> and the other workload which is a
301 - 400 of 3926 matches
Mail list logo
