Should check the return value of kzalloc first to avoid the null pointer.
Then can dereference the non-null pointer to access the fields of struct
resource.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
arch/tile/kernel/setup.c |4
1 file changed, 4 insertions(+)
diff --git
ccess the variable that has been out
through parse ASM code".
Please goto http://code.google.com/p/kgtp/wiki/UPDATE get more info
about this release.
According to the comments of Christoph, Geoff and Andi. I make lite
patch for review. Please goto https://lkml.org/lkml/2012/5/9/90 to
see it.
T
the variable that has been out
through parse ASM code.
Please goto http://code.google.com/p/kgtp/wiki/UPDATE get more info
about this release.
According to the comments of Christoph, Geoff and Andi. I make lite
patch for review. Please goto https://lkml.org/lkml/2012/5/9/90 to
see it.
Thanks,
Hui
the Chinese version.
Thanks,
Hui
On Wed, May 8, 2013 at 5:41 PM, Hui Zhu wrote:
> Hi guys,
>
> KGTP (http://code.google.com/p/kgtp/) is a flexible, lightweight and
> realtime Linux debugger and tracer.
> To use it, you don't need patch or rebuild the Linux kernel. Just
> build KGTP
the Chinese version.
Thanks,
Hui
On Wed, May 8, 2013 at 5:41 PM, Hui Zhu teawa...@gmail.com wrote:
Hi guys,
KGTP (http://code.google.com/p/kgtp/) is a flexible, lightweight and
realtime Linux debugger and tracer.
To use it, you don't need patch or rebuild the Linux kernel. Just
build KGTP module
核做单步
(Chinese version) get more info about it.
Please goto http://code.google.com/p/kgtp/wiki/UPDATE get more info
about this release.
According to the comments of Christoph, Geoff and Andi. I make lite
patch for review. Please goto https://lkml.org/lkml/2012/5/9/90 to
see it.
Thanks,
Hui
--
patch for review. Please goto https://lkml.org/lkml/2012/5/9/90 to
see it.
Thanks,
Hui
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
to
see it.
Thanks,
Hui
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to
see it.
Thanks,
Hui
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nicolas Pitre wrote:
On Fri, 1 Feb 2013, Hui Wang wrote:
Cyril Chemparathy wrote:
From: Vitaly Andrianov
This patch fixes the alloc_init_pud() function to use phys_addr_t instead of
unsigned long when passing in the phys argument.
This is an extension to commit
and devicemaps_init, from i know neither lowmem
nor device io registers of existing platforms exceed 32bit address.
regards,
Hui.
{
pud_t *pud = pud_offset(pgd, addr);
unsigned long next;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
but seems useless so far. This function only be
called from map_lowmem and devicemaps_init, from i know neither lowmem
nor device io registers of existing platforms exceed 32bit address.
regards,
Hui.
{
pud_t *pud = pud_offset(pgd, addr);
unsigned long next;
--
To unsubscribe
Nicolas Pitre wrote:
On Fri, 1 Feb 2013, Hui Wang wrote:
Cyril Chemparathy wrote:
From: Vitaly Andrianov vita...@ti.com
This patch fixes the alloc_init_pud() function to use phys_addr_t instead of
unsigned long when passing in the phys argument.
This is an extension to commit
On Sat, Jan 5, 2013 at 4:31 PM, Li Zhong wrote:
> On Sat, 2013-01-05 at 12:26 +0800, Hui Zhu wrote:
>> The comments of these WARN_ON_ONCE said "Can deadlock when called with
>> interrupts disabled".
>> But I didn't find anything that will block this function.
&g
On Sat, Jan 5, 2013 at 4:31 PM, Li Zhong zh...@linux.vnet.ibm.com wrote:
On Sat, 2013-01-05 at 12:26 +0800, Hui Zhu wrote:
The comments of these WARN_ON_ONCE said Can deadlock when called with
interrupts disabled.
But I didn't find anything that will block this function.
It seems that if two
>-Original Message-
>From: Simon Jeons [mailto:simon.je...@gmail.com]
>Sent: Sunday, January 06, 2013 5:20 PM
>To: Liu Hui-R64343
>Cc: Wanpeng Li; linux-kernel@vger.kernel.org; mgor...@suse.de;
>a...@linux-foundation.org; r...@redhat.com; minc...@kernel.org;
>kamezawa.
>-Original Message-
>From: Wanpeng Li [mailto:liw...@linux.vnet.ibm.com]
>Sent: Sunday, January 06, 2013 4:46 PM
>To: Liu Hui-R64343
>Cc: linux-kernel@vger.kernel.org; mgor...@suse.de; akpm@linux-
>foundation.org; r...@redhat.com; minc...@kernel.org;
>kamezawa.hir...@
>-Original Message-
>From: Wanpeng Li [mailto:liw...@linux.vnet.ibm.com]
>Sent: Sunday, January 06, 2013 4:00 PM
>To: Liu Hui-R64343
>Cc: linux-kernel@vger.kernel.org; mgor...@suse.de; akpm@linux-
>foundation.org; r...@redhat.com; minc...@kernel.org;
>kamezawa.hir...@
-Original Message-
From: Wanpeng Li [mailto:liw...@linux.vnet.ibm.com]
Sent: Sunday, January 06, 2013 4:00 PM
To: Liu Hui-R64343
Cc: linux-kernel@vger.kernel.org; mgor...@suse.de; akpm@linux-
foundation.org; r...@redhat.com; minc...@kernel.org;
kamezawa.hir...@jp.fujitsu.com; linux
-Original Message-
From: Wanpeng Li [mailto:liw...@linux.vnet.ibm.com]
Sent: Sunday, January 06, 2013 4:46 PM
To: Liu Hui-R64343
Cc: linux-kernel@vger.kernel.org; mgor...@suse.de; akpm@linux-
foundation.org; r...@redhat.com; minc...@kernel.org;
kamezawa.hir...@jp.fujitsu.com; linux
-Original Message-
From: Simon Jeons [mailto:simon.je...@gmail.com]
Sent: Sunday, January 06, 2013 5:20 PM
To: Liu Hui-R64343
Cc: Wanpeng Li; linux-kernel@vger.kernel.org; mgor...@suse.de;
a...@linux-foundation.org; r...@redhat.com; minc...@kernel.org;
kamezawa.hir...@jp.fujitsu.com; linux
>-Original Message-
>From: David Rientjes [mailto:rient...@google.com]
>Sent: Friday, December 28, 2012 6:39 AM
>To: Liu Hui-R64343
>Cc: Mel Gorman; linux-kernel@vger.kernel.org
>Subject: Re: echo 1 > /proc/sys/vm/compact_memory -> sh: write error: Bad
>address
I met one error when does the following command:
sh/$ echo 1 > /proc/sys/vm/compact_memory
sh/$ sh: write error: Bad address
After using strace, I find the following:
...
write(1, "1\n", 2) = 3
write(1, "", 4294967295)= -1 EFAULT (Bad address)
I met one error when does the following command:
sh/$ echo 1 /proc/sys/vm/compact_memory
sh/$ sh: write error: Bad address
After using strace, I find the following:
...
write(1, 1\n, 2) = 3
write(1, , 4294967295)= -1 EFAULT (Bad address)
write(2,
-Original Message-
From: David Rientjes [mailto:rient...@google.com]
Sent: Friday, December 28, 2012 6:39 AM
To: Liu Hui-R64343
Cc: Mel Gorman; linux-kernel@vger.kernel.org
Subject: Re: echo 1 /proc/sys/vm/compact_memory - sh: write error: Bad
address
On Thu, 27 Dec 2012, Liu Hui-R64343
On Mon, Dec 10, 2012 at 7:51 PM, Pawel Suchanecki wrote:
> 2012/12/10 Hui Zhu
>>
>> According to the comments of Christoph, Geoff and Andi. I make lite
>> patch for review. Please goto https://lkml.org/lkml/2012/5/9/90 to
>> see it.
>
> The patch you sent for r
On Mon, Dec 10, 2012 at 7:51 PM, Pawel Suchanecki sub...@gmail.com wrote:
2012/12/10 Hui Zhu teawa...@gmail.com
According to the comments of Christoph, Geoff and Andi. I make lite
patch for review. Please goto https://lkml.org/lkml/2012/5/9/90 to
see it.
The patch you sent for review used
for review. Please goto https://lkml.org/lkml/2012/5/9/90 to
see it.
Thanks,
Hui
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
for review. Please goto https://lkml.org/lkml/2012/5/9/90 to
see it.
Thanks,
Hui
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
I'm hitting this under a heavy scheduler test load with SCHED_RR tasks
exiting normally after completion and the parent exiting with some of
the pthreads still running:
(gdb) bt
#0 no_context (regs=0x880018c55d58, error_code=0, address=4,
signal=signal@entry=11,
I'm hitting this under a heavy scheduler test load with SCHED_RR tasks
exiting normally after completion and the parent exiting with some of
the pthreads still running:
(gdb) bt
#0 no_context (regs=0x880018c55d58, error_code=0, address=4,
signal=signal@entry=11,
io_ctl_map_page is called by many functions in free-space-cache.
In most scenarios, the ->cur is not null, e.g. io_ctl_add_entry.
I think we'd better remove the warn_on here.
Signed-off-by: Wang Sheng-Hui
---
fs/btrfs/free-space-cache.c |1 -
1 files changed, 0 insertions(+), 1 deleti
io_ctl_map_page is called by many functions in free-space-cache.
In most scenarios, the -cur is not null, e.g. io_ctl_add_entry.
I think we'd better remove the warn_on here.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/btrfs/free-space-cache.c |1 -
1 files changed, 0 insertions
In csum_dirty_buffer, we first get eb from page->private.
Then we check if the page is the first page of eb. Later
we check it again. Remove the repeated check here.
Signed-off-by: Wang Sheng-Hui
---
fs/btrfs/disk-io.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
d
In csum_dirty_buffer, we first get eb from page-private.
Then we check if the page is the first page of eb. Later
we check it again. Remove the repeated check here.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/btrfs/disk-io.c |8 +++-
1 files changed, 3 insertions(+), 5
On 2012年09月25日 00:17, David Sterba wrote:
> On Mon, Sep 24, 2012 at 12:38:07PM +0800, Wang Sheng-Hui wrote:
>> Check range early to avoid further check/compute in case
>> of range error.
>>
>> Signed-off-by: Wang Sheng-Hui
>> ---
>> fs/btrfs/extent_i
On 2012年09月25日 00:17, David Sterba wrote:
On Mon, Sep 24, 2012 at 12:38:07PM +0800, Wang Sheng-Hui wrote:
Check range early to avoid further check/compute in case
of range error.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/btrfs/extent_io.c | 16
1 files
Check range early to avoid further check/compute in case
of range error.
Signed-off-by: Wang Sheng-Hui
---
fs/btrfs/extent_io.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 4c87847..9250cf5 100644
Check range early to avoid further check/compute in case
of range error.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/btrfs/extent_io.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 4c87847
. I make lite
patch for review. Please goto https://lkml.org/lkml/2012/5/9/90 to
see it.
Thanks,
Hui
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
The action has been merged into struct btrfs_delayed_ref_node,
and no struct btrfs_delayed_ref is available now.
Signed-off-by: Wang Sheng-Hui
---
fs/btrfs/delayed-ref.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/delayed-ref.h b/fs/btrfs/delayed-ref.h
The action has been merged into struct btrfs_delayed_ref_node,
and no struct btrfs_delayed_ref is available now.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/btrfs/delayed-ref.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/delayed-ref.h b/fs/btrfs
. I make lite
patch for review. Please goto https://lkml.org/lkml/2012/5/9/90 to
see it.
Thanks,
Hui
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
To check the duplicated super blocks, use BTRFS_SUPER_MIRROR_MAX
as the loops limit.
Signed-off-by: Wang Sheng-Hui
---
fs/btrfs/disk-io.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 22e98e0..a431144 100644
--- a/fs
To check the duplicated super blocks, use BTRFS_SUPER_MIRROR_MAX
as the loops limit.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/btrfs/disk-io.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 22e98e0..a431144
The function scans @delaying_queue and stops at the first inode
whose dirtied_when is after *work->older_than_this. So the expired
ones being moved are those before *work->older_than_this. Correct
the comment here.
Signed-off-by: Wang Sheng-Hui
---
fs/fs-writeback.c |2 +-
1 files c
The function scans @delaying_queue and stops at the first inode
whose dirtied_when is after *work-older_than_this. So the expired
ones being moved are those before *work-older_than_this. Correct
the comment here.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/fs-writeback.c |2 +-
1
On 2012年09月06日 18:09, David Sterba wrote:
> On Thu, Sep 06, 2012 at 02:40:41PM +0800, Wang Sheng-Hui wrote:
>> The memory allocation failure is BUG_ON in add_excluded_extent (following
>> the code path) and btrfs_rmap_block. No need to BUG_ON -ENOMEM inside
>> exclude
The memory allocation failure will be catched in set_extent_bits.
Always return 0 is useless for its callers.
Signed-off-by: Wang Sheng-Hui
---
fs/btrfs/extent-tree.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index
The memory allocation failure is BUG_ON in add_excluded_extent
(following the code path). No need to BUG_ON -ENOMEM inside
btrfs_alloc_logged_file_extent.
Signed-off-by: Wang Sheng-Hui
---
fs/btrfs/extent-tree.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs
-Hui
---
fs/btrfs/extent-tree.c | 20 +++-
1 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index ba58024..95492cc 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -234,39 +234,33 @@ static void
-Hui shh...@gmail.com
---
fs/btrfs/extent-tree.c | 20 +++-
1 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index ba58024..95492cc 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -234,39 +234,33
The memory allocation failure is BUG_ON in add_excluded_extent
(following the code path). No need to BUG_ON -ENOMEM inside
btrfs_alloc_logged_file_extent.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/btrfs/extent-tree.c |6 ++
1 files changed, 2 insertions(+), 4 deletions
The memory allocation failure will be catched in set_extent_bits.
Always return 0 is useless for its callers.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/btrfs/extent-tree.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs
On 2012年09月06日 18:09, David Sterba wrote:
On Thu, Sep 06, 2012 at 02:40:41PM +0800, Wang Sheng-Hui wrote:
The memory allocation failure is BUG_ON in add_excluded_extent (following
the code path) and btrfs_rmap_block. No need to BUG_ON -ENOMEM inside
exclude_super_stripes itself.
No please
The count records the PAs freed, not left.
Change the debug description.
Signed-off-by: Wang Sheng-Hui
---
fs/ext4/mballoc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 8eae947..f83b145 100644
--- a/fs/ext4/mballoc.c
The count records the PAs freed, not left.
Change the debug description.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/ext4/mballoc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 8eae947..f83b145 100644
--- a/fs
o https://lkml.org/lkml/2012/5/9/90 to
see it.
Thanks,
Hui
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to
see it.
Thanks,
Hui
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
In the check code above, if orig_start != donor_start, we would
return -EINVAL. So here, orig_start should be equal with donor_start.
Remove the redundant check here.
Signed-off-by: Wang Sheng-Hui
---
fs/ext4/move_extent.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git
In the check code above, if orig_start != donor_start, we would
return -EINVAL. So here, orig_start should be equal with donor_start.
Remove the redundant check here.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/ext4/move_extent.c |1 -
1 files changed, 0 insertions(+), 1 deletions
Put the sign '/' to the right position.
Signed-off-by: Wang Sheng-Hui
---
fs/ext4/extents.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 7f6fb48..f394e0f 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -3241,7
Put the sign '/' to the right position.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/ext4/extents.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 7f6fb48..f394e0f 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4
In function __generic_block_fiemap, local var past_eof is declared
as bool, so use 'true' instead of number 1 here.
Signed-off-by: Wang Sheng-Hui
---
fs/ioctl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/ioctl.c b/fs/ioctl.c
index 29167be..e42abb0 100644
In function __generic_block_fiemap, local var past_eof is declared
as bool, so use 'true' instead of number 1 here.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/ioctl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/ioctl.c b/fs/ioctl.c
index 29167be
On 2012年07月07日 23:15, Zheng Liu wrote:
> Hi Sheng-Hui,
>
> It seems that there has a patch to fix it.
> http://www.spinics.net/lists/linux-ext4/msg32611.html
>
> Regards,
> Zheng
Got it.
I didn't track the patch list. Just checked the git tree.
Thanks,
>
> On
On 2012年07月07日 23:15, Zheng Liu wrote:
Hi Sheng-Hui,
It seems that there has a patch to fix it.
http://www.spinics.net/lists/linux-ext4/msg32611.html
Regards,
Zheng
Got it.
I didn't track the patch list. Just checked the git tree.
Thanks,
On Fri, Jul 6, 2012 at 2:26 PM, Wang Sheng
On Sun, Feb 24, 2008 at 10:21 PM, Bill Huey (hui) <[EMAIL PROTECTED]> wrote:
> It's probably safe to use, but it's not what its original purpose was
> and you should use another function/macro. This is an annotation issue
> and your use of it is inconsistent with how it's us
On Sun, Feb 24, 2008 at 10:21 PM, Bill Huey (hui) [EMAIL PROTECTED] wrote:
It's probably safe to use, but it's not what its original purpose was
and you should use another function/macro. This is an annotation issue
and your use of it is inconsistent with how it's used in voluntary
preempt
[repost with all folks CCed]
On Sun, Feb 24, 2008 at 9:20 PM, Gregory Haskins
<[EMAIL PROTECTED]> wrote:
> Are you saying that the modified logic that I introduced is broken? Or
> that the original use of the might_sleep() annotation inside this
> function is broken?
It's probably safe to
[repost with all folks CCed]
On Sun, Feb 24, 2008 at 9:20 PM, Gregory Haskins
[EMAIL PROTECTED] wrote:
Are you saying that the modified logic that I introduced is broken? Or
that the original use of the might_sleep() annotation inside this
function is broken?
It's probably safe to use,
On Fri, Feb 22, 2008 at 2:20 PM, Gregory Haskins
<[EMAIL PROTECTED]> wrote:
> Agreed, but it's still correct afaict. I added an extra might_sleep()
> to a path that really might sleep. I should have mentioned that in the
> header.
>
> In any case, its moot. Andi indicated this patch is
On Fri, Feb 22, 2008 at 11:19 AM, Bill Huey (hui) <[EMAIL PROTECTED]> wrote:
> Yeah, I'm not very keen on having a constant there without some
> contention instrumentation to see how long the spins are. It would be
> better to just let it run until either task->on_cpu
On Fri, Feb 22, 2008 at 11:08 AM, Paul E. McKenney
<[EMAIL PROTECTED]> wrote:
> One approach would be to set the RTLOCK_DELAY parameter to something like
> -1 for default, and to set it to the number of cycles required for about
> 10 cache misses at boot time. This would automatically scale
On Fri, Feb 22, 2008 at 11:08 AM, Paul E. McKenney
[EMAIL PROTECTED] wrote:
One approach would be to set the RTLOCK_DELAY parameter to something like
-1 for default, and to set it to the number of cycles required for about
10 cache misses at boot time. This would automatically scale with
On Fri, Feb 22, 2008 at 11:19 AM, Bill Huey (hui) [EMAIL PROTECTED] wrote:
Yeah, I'm not very keen on having a constant there without some
contention instrumentation to see how long the spins are. It would be
better to just let it run until either task-on_cpu is off or checking
On Fri, Feb 22, 2008 at 2:20 PM, Gregory Haskins
[EMAIL PROTECTED] wrote:
Agreed, but it's still correct afaict. I added an extra might_sleep()
to a path that really might sleep. I should have mentioned that in the
header.
In any case, its moot. Andi indicated this patch is probably a
It would also help to get the lockdep/lockstat output for those runs
so that more discussion can happen. That framework can be extended to
do all sorts of contention tracking and that is why I took implemented
it in the first place to track the viability of adaptive spins. My
initial results where
It would also help to get the lockdep/lockstat output for those runs
so that more discussion can happen. That framework can be extended to
do all sorts of contention tracking and that is why I took implemented
it in the first place to track the viability of adaptive spins. My
initial results where
Folks,
The official announcement.
http://www.netapp.com/news/press/news_rel_20070905
Dave Hitz's blog about it.
http://blogs.netapp.com/dave/
bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Folks,
The official announcement.
http://www.netapp.com/news/press/news_rel_20070905
Dave Hitz's blog about it.
http://blogs.netapp.com/dave/
bill
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Sun, Jul 29, 2007 at 04:18:18PM -0700, Linus Torvalds wrote:
> Ingo posted numbers. Look at those numbers, and then I would suggest some
> people could seriously consider just shutting up. I've seen too many
> idiotic people who claim that Con got treated unfairly, without those
> people
On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote:
> And I think you are digressing from the main issue, which is the empirical
> comparison of SD vs. CFS and to determine which is best. The root of all
> the scheduler fuss was the emotional reaction of SD's author on why his
>
On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote:
And I think you are digressing from the main issue, which is the empirical
comparison of SD vs. CFS and to determine which is best. The root of all
the scheduler fuss was the emotional reaction of SD's author on why his
On Sun, Jul 29, 2007 at 04:18:18PM -0700, Linus Torvalds wrote:
Ingo posted numbers. Look at those numbers, and then I would suggest some
people could seriously consider just shutting up. I've seen too many
idiotic people who claim that Con got treated unfairly, without those
people
On Sun, Jul 29, 2007 at 10:25:42PM +0200, Mike Galbraith wrote:
> Absolutely.
>
> Con quit for his own reasons. Given that Con himself has said that CFS
> was _not_ why he quite, please discard this... bait. Anyone who's name
> isn't Con Kolivas, who pretends to speak for him is at the very
On Sun, Jul 29, 2007 at 10:25:42PM +0200, Mike Galbraith wrote:
Absolutely.
Con quit for his own reasons. Given that Con himself has said that CFS
was _not_ why he quite, please discard this... bait. Anyone who's name
isn't Con Kolivas, who pretends to speak for him is at the very least
On Sat, Jul 28, 2007 at 03:18:24PM -0700, Linus Torvalds wrote:
> I don't think anything was suppressed here.
I disagree. See below.
> You seem to say that more modular code would have helped make for a nicer
> way to do schedulers, but if so, where were those patches to do that?
> Con's
On Sat, Jul 28, 2007 at 11:06:09PM +0200, Diego Calleja wrote:
> So your argument is that SD shouldn't have been merged either, because it
> would have resulted in one scheduler over the other?
My argument is that schedule development is open ended. Although having
a central scheduler to hack is
On Sat, Jul 28, 2007 at 09:28:36PM +0200, jos poortvliet wrote:
> Your point here seems to be: this is how it went, and it was right. Ok, got
> that. Yet, Con walked away (and not just over SD). Seeing Con go, I wonder
> how many did leave without this splash. How many didn't even get involved
On Sat, Jul 28, 2007 at 09:28:36PM +0200, jos poortvliet wrote:
Your point here seems to be: this is how it went, and it was right. Ok, got
that. Yet, Con walked away (and not just over SD). Seeing Con go, I wonder
how many did leave without this splash. How many didn't even get involved at
On Sat, Jul 28, 2007 at 11:06:09PM +0200, Diego Calleja wrote:
So your argument is that SD shouldn't have been merged either, because it
would have resulted in one scheduler over the other?
My argument is that schedule development is open ended. Although having
a central scheduler to hack is a
On Sat, Jul 28, 2007 at 03:18:24PM -0700, Linus Torvalds wrote:
I don't think anything was suppressed here.
I disagree. See below.
You seem to say that more modular code would have helped make for a nicer
way to do schedulers, but if so, where were those patches to do that?
Con's patches
On Fri, Jul 27, 2007 at 07:36:17PM -0400, Chris Snook wrote:
> I don't think that achieving a constant error bound is always a good thing.
> We all know that fairness has overhead. If I have 3 threads and 2
> processors, and I have a choice between fairly giving each thread 1.0
> billion
On Fri, Jul 27, 2007 at 12:03:28PM -0700, Tong Li wrote:
> Thanks for the interest. Attached is a design doc I wrote several months
> ago (with small modifications). It talks about the two pieces of my design:
> group scheduling and dwrr. The description was based on the original O(1)
>
On Fri, Jul 27, 2007 at 12:03:28PM -0700, Tong Li wrote:
Thanks for the interest. Attached is a design doc I wrote several months
ago (with small modifications). It talks about the two pieces of my design:
group scheduling and dwrr. The description was based on the original O(1)
scheduler,
On Fri, Jul 27, 2007 at 07:36:17PM -0400, Chris Snook wrote:
I don't think that achieving a constant error bound is always a good thing.
We all know that fairness has overhead. If I have 3 threads and 2
processors, and I have a choice between fairly giving each thread 1.0
billion cycles
On Tue, Jul 24, 2007 at 05:22:47PM -0400, Chris Snook wrote:
> Bill Huey (hui) wrote:
> Well, you need enough CPU time to meet your deadlines. You need
> pre-allocated memory, or to be able to guarantee that you can allocate
> memory fast enough to meet your deadlines. This princ
On Tue, Jul 24, 2007 at 04:39:47PM -0400, Chris Snook wrote:
> Chris Friesen wrote:
>> We currently use CKRM on an SMP machine, but the only way we can get away
>> with it is because our main app is affined to one cpu and just about
>> everything else is affined to the other.
>
> If you're not
On Tue, Jul 24, 2007 at 04:39:47PM -0400, Chris Snook wrote:
Chris Friesen wrote:
We currently use CKRM on an SMP machine, but the only way we can get away
with it is because our main app is affined to one cpu and just about
everything else is affined to the other.
If you're not explicitly
601 - 700 of 907 matches
Mail list logo
