Signed-off-by: Ken Chen <chen.ke...@inventec.com>
---
v1->v2
- Merged PCA9641 code into i2c-mux-pca9541.c
- Modified title
- Add PCA9641 detect function
---
drivers/i2c/muxes/i2c-mux-pca9541.c | 184 ++--
1 file changed, 174 insertions(+), 10 deletions
Signed-off-by: Ken Chen
---
v1->v2
- Merged PCA9641 code into i2c-mux-pca9541.c
- Modified title
- Add PCA9641 detect function
---
drivers/i2c/muxes/i2c-mux-pca9541.c | 184 ++--
1 file changed, 174 insertions(+), 10 deletions(-)
diff --git a/drivers/i2c/mu
Initial PCA9641 2 chennel I2C bus master arbiter
with separate implementation. It has probe issue
and difference device hehavior between PCA9541
and PCA9641 in original PCA9641 patch.
Signed-off-by: Ken Chen <chen.ke...@inventec.com>
---
drivers/i2c/muxes/Kconfig | 9 +
drive
Initial PCA9641 2 chennel I2C bus master arbiter
with separate implementation. It has probe issue
and difference device hehavior between PCA9541
and PCA9641 in original PCA9641 patch.
Signed-off-by: Ken Chen
---
drivers/i2c/muxes/Kconfig | 9 +
drivers/i2c/muxes/Makefile
On Thu, Sep 4, 2014 at 6:20 AM, Kirill Smelkov wrote:
> Commit 75897d60 (hugetlb: allow sticky directory mount option) added
> support for mounting hugetlbfs with sticky option set, like /tmp is
> usually mounted, but forgot to document that.
>
> Cc: Ken Chen
> Signed-off-
On Thu, Sep 4, 2014 at 6:20 AM, Kirill Smelkov k...@nexedi.com wrote:
Commit 75897d60 (hugetlb: allow sticky directory mount option) added
support for mounting hugetlbfs with sticky option set, like /tmp is
usually mounted, but forgot to document that.
Cc: Ken Chen kenc...@google.com
Signed
_fault() is called with the right write_access parameter.
>
> Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
Adam, this looks good.
Reviewed-by: Ken Chen <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
parameter.
Signed-off-by: Adam Litke [EMAIL PROTECTED]
Adam, this looks good.
Reviewed-by: Ken Chen [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
On 10/18/07, Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> Good question indeed. How large is this memory footprint exactly ? If it
> is as small as you say, I suspect that the real issue could be that
> these variable are accessed by the scheduler critical paths and
> therefore trash the caches.
On 10/18/07, Mathieu Desnoyers [EMAIL PROTECTED] wrote:
Good question indeed. How large is this memory footprint exactly ? If it
is as small as you say, I suspect that the real issue could be that
these variable are accessed by the scheduler critical paths and
therefore trash the caches.
On 10/16/07, Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 16, 2007 at 12:07:06PM -0700, Ken Chen wrote:
> > We recently discovered a nasty performance bug in the kernel CPU load
> > balancer where we were hit by 50% performance regression.
> >
> > Wh
On 10/16/07, Siddha, Suresh B [EMAIL PROTECTED] wrote:
On Tue, Oct 16, 2007 at 12:07:06PM -0700, Ken Chen wrote:
We recently discovered a nasty performance bug in the kernel CPU load
balancer where we were hit by 50% performance regression.
When tasks are assigned to a subset of CPUs
system).
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 592e3a5..311a8bd 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -562,7 +562,7 @@ struct sched_info {
last_queued; /* when w
ce goes into spread
mode instead of default grouping mode.
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
--- ./kernel/sched.c.orig 2007-10-16 10:08:01.0 -0700
+++ ./kernel/sched.c2007-10-16 10:56:13.0 -0700
@@ -2339,7 +2339,7 @@
unsigned long max_
.
Signed-off-by: Ken Chen [EMAIL PROTECTED]
--- ./kernel/sched.c.orig 2007-10-16 10:08:01.0 -0700
+++ ./kernel/sched.c2007-10-16 10:56:13.0 -0700
@@ -2339,7 +2339,7 @@
unsigned long max_pull;
unsigned long busiest_load_per_task, busiest_nr_running
system).
Signed-off-by: Ken Chen [EMAIL PROTECTED]
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 592e3a5..311a8bd 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -562,7 +562,7 @@ struct sched_info {
last_queued; /* when we were
On 10/3/07, Dave Hansen <[EMAIL PROTECTED]> wrote:
> > Not quite. Count can never go below the number of reserved pages plus
> > pages allocated to MAP_PRIVATE mappings. That number is computed by:
> > (resv + (total - free)).
>
> So, (total - free) equals the number of MAP_PRIVATE pages? Does
elow it; and (2) both try_to_free_low() and the while loop
below the call to try_to_free_low() will terminate correctly. If you
feel like it, please clean it up as well.
If not, I'm fine with that.
Acked-by: Ken Chen <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "un
() and the while loop
below the call to try_to_free_low() will terminate correctly. If you
feel like it, please clean it up as well.
If not, I'm fine with that.
Acked-by: Ken Chen [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On 10/3/07, Dave Hansen [EMAIL PROTECTED] wrote:
Not quite. Count can never go below the number of reserved pages plus
pages allocated to MAP_PRIVATE mappings. That number is computed by:
(resv + (total - free)).
So, (total - free) equals the number of MAP_PRIVATE pages? Does that
On 6/11/07, Adam Litke <[EMAIL PROTECTED]> wrote:
On 6/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> -struct file *hugetlb_zero_setup(size_t size)
> +struct file *hugetlb_file_setup(const char *name, size_t size)
The bulk of this patch seems to handle renaming this function. Is
that
On 6/11/07, Adam Litke [EMAIL PROTECTED] wrote:
On 6/8/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
-struct file *hugetlb_zero_setup(size_t size)
+struct file *hugetlb_file_setup(const char *name, size_t size)
The bulk of this patch seems to handle renaming this function. Is
that really
l user space
tools as the tools are not ready to cope with the "on-demand feature". Fix
it by instantiate default 8 loop devices and also reinstate max_loop module
parameter.
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
Acked-by: Al Viro <[EMAIL PROTECTED]>
diff --git a/dr
tools as the tools are not ready to cope with the on-demand feature. Fix
it by instantiate default 8 loop devices and also reinstate max_loop module
parameter.
Signed-off-by: Ken Chen [EMAIL PROTECTED]
Acked-by: Al Viro [EMAIL PROTECTED]
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
On 5/31/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
I have a note here that it needs additional work. This discussion:
http://lkml.org/lkml/2007/5/21/602
seemed to peter out and go nowhere?
The first rev went in -mm needs work and the above url is the result
of feedback from Al Viro. He
On 5/31/07, walt <[EMAIL PROTECTED]> wrote:
Ken Chen wrote:
> On 5/21/07, Ken Chen <[EMAIL PROTECTED]> wrote:
...
> tested, like this?
Ken, your patch below works for me. Are you going to send this
on to Linus?
I think akpm will route this to Linus. andrew?
-
To unsubscr
On 5/31/07, walt [EMAIL PROTECTED] wrote:
Ken Chen wrote:
On 5/21/07, Ken Chen [EMAIL PROTECTED] wrote:
...
tested, like this?
Ken, your patch below works for me. Are you going to send this
on to Linus?
I think akpm will route this to Linus. andrew?
-
To unsubscribe from this list: send
On 5/31/07, Andrew Morton [EMAIL PROTECTED] wrote:
I have a note here that it needs additional work. This discussion:
http://lkml.org/lkml/2007/5/21/602
seemed to peter out and go nowhere?
The first rev went in -mm needs work and the above url is the result
of feedback from Al Viro. He
On 5/21/07, Ken Chen <[EMAIL PROTECTED]> wrote:
On 5/21/07, Al Viro <[EMAIL PROTECTED]> wrote:
> No, it doesn't. Really. It's easy to split; untested incremental to your
> patch follows:
>
> for (i = 0; i < nr; i++) {
> -
On 5/21/07, Al Viro <[EMAIL PROTECTED]> wrote:
No, it doesn't. Really. It's easy to split; untested incremental to your
patch follows:
for (i = 0; i < nr; i++) {
- if (!loop_init_one(i))
- goto err;
+ lo = loop_alloc(i);
+
On 5/21/07, Al Viro <[EMAIL PROTECTED]> wrote:
On Mon, May 21, 2007 at 03:00:55PM -0700, [EMAIL PROTECTED] wrote:
> + if (register_blkdev(LOOP_MAJOR, "loop"))
> + return -EIO;
> + blk_register_region(MKDEV(LOOP_MAJOR, 0), range,
> + THIS_MODULE,
On 5/21/07, Ken Chen <[EMAIL PROTECTED]> wrote:
The easiest way is to reinstate max_loop and create "max_loop" device
up front at module load time. However, that will lose all the "fancy
on-demand device instantiation feature".
So I propose we do the following:
On 5/21/07, Ken Chen <[EMAIL PROTECTED]> wrote:
yes and no. in that commit, I automatically create n+1 device when
loop device n is created, allergically was tested to be fine with
casual usage of "losetup" and "mount -o loop". However, there is a
bug in that commi
On 5/21/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
Yes. Can somebody who actually _uses_ loop send a tested patch, please?
We're not going to break existing user space over something idiotic like
this. Not acceptable.
The alternative is to just revert all the loop.c patches. Which I'll do
3722a0eb39d4932
Author: Al Viro <[EMAIL PROTECTED]>
Date: Sat May 12 16:23:15 2007 -0400
fix the dynamic allocation and probe in loop.c
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Acked-by: Ken Chen <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PR
[EMAIL PROTECTED]
Date: Sat May 12 16:23:15 2007 -0400
fix the dynamic allocation and probe in loop.c
Signed-off-by: Al Viro [EMAIL PROTECTED]
Acked-by: Ken Chen [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line
On 5/21/07, Linus Torvalds [EMAIL PROTECTED] wrote:
Yes. Can somebody who actually _uses_ loop send a tested patch, please?
We're not going to break existing user space over something idiotic like
this. Not acceptable.
The alternative is to just revert all the loop.c patches. Which I'll do
On 5/21/07, Ken Chen [EMAIL PROTECTED] wrote:
yes and no. in that commit, I automatically create n+1 device when
loop device n is created, allergically was tested to be fine with
casual usage of losetup and mount -o loop. However, there is a
bug in that commit when loop.c was compiled
On 5/21/07, Ken Chen [EMAIL PROTECTED] wrote:
The easiest way is to reinstate max_loop and create max_loop device
up front at module load time. However, that will lose all the fancy
on-demand device instantiation feature.
So I propose we do the following:
1. have the module honor max_loop
On 5/21/07, Al Viro [EMAIL PROTECTED] wrote:
On Mon, May 21, 2007 at 03:00:55PM -0700, [EMAIL PROTECTED] wrote:
+ if (register_blkdev(LOOP_MAJOR, loop))
+ return -EIO;
+ blk_register_region(MKDEV(LOOP_MAJOR, 0), range,
+ THIS_MODULE,
On 5/21/07, Al Viro [EMAIL PROTECTED] wrote:
No, it doesn't. Really. It's easy to split; untested incremental to your
patch follows:
for (i = 0; i nr; i++) {
- if (!loop_init_one(i))
- goto err;
+ lo = loop_alloc(i);
+
On 5/21/07, Ken Chen [EMAIL PROTECTED] wrote:
On 5/21/07, Al Viro [EMAIL PROTECTED] wrote:
No, it doesn't. Really. It's easy to split; untested incremental to your
patch follows:
for (i = 0; i nr; i++) {
- if (!loop_init_one(i))
- goto err
k(domain->lock);
for (p = domain->probes[MAJOR(dev) % 255]; p; p = p->next) {
...
if (kobj)
return kobj;
goto retry;
}
So loop_probe() mistakenly returned wrong status and leads to future
oops on inconsistent module ref count. The following patch f
) % 255]; p; p = p-next) {
...
if (kobj)
return kobj;
goto retry;
}
So loop_probe() mistakenly returned wrong status and leads to future
oops on inconsistent module ref count. The following patch fixes the
issue.
Signed-off-by: Ken Chen [EMAIL PROTECTED]
diff
On 5/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
Note, Ken, that if we did that, the calculation of these new Total and
Free stats would be a little different than your new code. Instead of
looping over the memory nodes in the current tasks mems_allowed mask,
we would loop over the memory
On 5/3/07, Paul Jackson [EMAIL PROTECTED] wrote:
Note, Ken, that if we did that, the calculation of these new Total and
Free stats would be a little different than your new code. Instead of
looping over the memory nodes in the current tasks mems_allowed mask,
we would loop over the memory nodes
On 5/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
Adding Christoph Lameter <[EMAIL PROTECTED]> to the cc list, as he knows
more about hugetlb pages than I do.
This patch strikes me as a bit odd.
Granted, it's solving what could be a touchy problem with a fairly
simple solution, which is
On 5/3/07, Paul Jackson [EMAIL PROTECTED] wrote:
Adding Christoph Lameter [EMAIL PROTECTED] to the cc list, as he knows
more about hugetlb pages than I do.
This patch strikes me as a bit odd.
Granted, it's solving what could be a touchy problem with a fairly
simple solution, which is usually a
On 5/1/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
Fair enough, it is a bit of an ugly thing. And I see no measurements there
on what the overall speedup was for any workload.
Ken, which memory model was in use? sparsemem?
discontigmem with config_numa on.
-
To unsubscribe from this list:
On 5/1/07, Andrew Morton [EMAIL PROTECTED] wrote:
Fair enough, it is a bit of an ugly thing. And I see no measurements there
on what the overall speedup was for any workload.
Ken, which memory model was in use? sparsemem?
discontigmem with config_numa on.
-
To unsubscribe from this list:
On 4/12/07, Ken Chen <[EMAIL PROTECTED]> wrote:
On 4/12/07, Jeff Moyer <[EMAIL PROTECTED]> wrote:
> I didn't see any response to Zach's request for code that actually
> tests out the shared ring buffer. Do you have such code?
Yes, I do. I was stress testing the code since
On 4/12/07, Jeff Moyer <[EMAIL PROTECTED]> wrote:
I didn't see any response to Zach's request for code that actually
tests out the shared ring buffer. Do you have such code?
Yes, I do. I was stress testing the code since last night. After 20+
hours of stress run with fio and aio-stress, now
t word?)
From: Ken Chen <[EMAIL PROTECTED]>
Resurrect an old patch that uses atomic operation to update ring buffer
index on AIO event queue. This work allows further application/libaio
optimization to run fast path io_getevents in user space.
I've also added one more change o
On 4/11/07, Ken Chen <[EMAIL PROTECTED]> wrote:
On 4/11/07, Zach Brown <[EMAIL PROTECTED]> wrote:
> First, I'll NAK this and all AIO patches until the patch description
> says that it's been run through the regression tests that we've started
> collecting in autotest. T
On 4/11/07, Ken Chen [EMAIL PROTECTED] wrote:
On 4/11/07, Zach Brown [EMAIL PROTECTED] wrote:
First, I'll NAK this and all AIO patches until the patch description
says that it's been run through the regression tests that we've started
collecting in autotest. They're trivial to run, never
?)
From: Ken Chen [EMAIL PROTECTED]
Resurrect an old patch that uses atomic operation to update ring buffer
index on AIO event queue. This work allows further application/libaio
optimization to run fast path io_getevents in user space.
I've also added one more change on top of old implementation
On 4/12/07, Jeff Moyer [EMAIL PROTECTED] wrote:
I didn't see any response to Zach's request for code that actually
tests out the shared ring buffer. Do you have such code?
Yes, I do. I was stress testing the code since last night. After 20+
hours of stress run with fio and aio-stress, now
On 4/12/07, Ken Chen [EMAIL PROTECTED] wrote:
On 4/12/07, Jeff Moyer [EMAIL PROTECTED] wrote:
I didn't see any response to Zach's request for code that actually
tests out the shared ring buffer. Do you have such code?
Yes, I do. I was stress testing the code since last night. After 20
On 4/11/07, Zach Brown <[EMAIL PROTECTED]> wrote:
First, I'll NAK this and all AIO patches until the patch description
says that it's been run through the regression tests that we've started
collecting in autotest. They're trivial to run, never fear:
OK. I will run those regression tests.
On 4/11/07, Zach Brown <[EMAIL PROTECTED]> wrote:
> Sorry I wasn't thorough enough. And partially because I was worried
> about changing structure type for user space facing struct aio_ring.
> Now that I looked through all arches, it looks safe as all arch's
> atomic_t has the same size as int.
On 4/10/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Tue, 10 Apr 2007 16:53:53 -0700 (PDT) [EMAIL PROTECTED] (Ken Chen) wrote:
> + } while (head != cmpxchg(>head, head, head + 1));
A hasty grep indicates that only 14 out of 23 architectures implement
cmpxchg().
Sorry I was
On 4/11/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
On Wed, 2007-04-11 at 17:53 +0800, Zhao Forrest wrote:
> I got some new information:
> Before soft lockup message is out, we have:
> [EMAIL PROTECTED] home]# cat /proc/slabinfo |grep buffer_head
> buffer_head 10927942 10942560120
On 4/11/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
On Wed, 2007-04-11 at 17:53 +0800, Zhao Forrest wrote:
I got some new information:
Before soft lockup message is out, we have:
[EMAIL PROTECTED] home]# cat /proc/slabinfo |grep buffer_head
buffer_head 10927942 10942560120 32
On 4/10/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 10 Apr 2007 16:53:53 -0700 (PDT) [EMAIL PROTECTED] (Ken Chen) wrote:
+ } while (head != cmpxchg(ring-head, head, head + 1));
A hasty grep indicates that only 14 out of 23 architectures implement
cmpxchg().
Sorry I wasn't
On 4/11/07, Zach Brown [EMAIL PROTECTED] wrote:
Sorry I wasn't thorough enough. And partially because I was worried
about changing structure type for user space facing struct aio_ring.
Now that I looked through all arches, it looks safe as all arch's
atomic_t has the same size as int.
On 4/11/07, Zach Brown [EMAIL PROTECTED] wrote:
First, I'll NAK this and all AIO patches until the patch description
says that it's been run through the regression tests that we've started
collecting in autotest. They're trivial to run, never fear:
OK. I will run those regression tests.
to power of 2 to allow fast head/tail calculation. With
the new scheme, there is no more modulo operation on them and we simply
increment either pointer index directly. This scheme also automatically
handles integer wrap nicely without any additional special treatment.
Signed-off-by: Ken Chen <[EM
to power of 2 to allow fast head/tail calculation. With
the new scheme, there is no more modulo operation on them and we simply
increment either pointer index directly. This scheme also automatically
handles integer wrap nicely without any additional special treatment.
Signed-off-by: Ken Chen [EMAIL
On 4/1/07, Tomas M <[EMAIL PROTECTED]> wrote:
I believe that IF you _really_ need to preserve the max_loop module
parameter, then the parameter should _not_ be ignored, rather it should
have the same function like before - to limit the loop driver so if you
use max_loop=10 for example, it should
On 4/1/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
not sure if this is a real issue and if it`s UML or loop related -
but how is low-memory situations being handled when
creating loop devices ?
kernel returns -ENOMEM as an error code if there are no memory left to
initialize loop device.
On 4/1/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
not sure if this is a real issue and if it`s UML or loop related -
but how is low-memory situations being handled when
creating loop devices ?
kernel returns -ENOMEM as an error code if there are no memory left to
initialize loop device.
On 4/1/07, Tomas M [EMAIL PROTECTED] wrote:
I believe that IF you _really_ need to preserve the max_loop module
parameter, then the parameter should _not_ be ignored, rather it should
have the same function like before - to limit the loop driver so if you
use max_loop=10 for example, it should
email client
decide to eat away white spaces for the in-line text.
--
Subject: remove artificial software max_loop limit
From: "Ken Chen" <[EMAIL PROTECTED]>
Remove artificial maximum 256 loop device that can be created due to a
leg
away white spaces for the in-line text.
--
Subject: remove artificial software max_loop limit
From: Ken Chen [EMAIL PROTECTED]
Remove artificial maximum 256 loop device that can be created due to a
legacy device number limit. Searching through
On 3/30/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
So.. this change will cause a fatal error for anyone who is presently
using max_loop, won't it? If they're doing that within their
initramfs/initrd/etc then things could get rather ugly for them.
probably, if they access loop device
On 3/30/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> lo->lo_device = NULL;
> lo->lo_backing_file = NULL;
> lo->lo_flags = 0;
> - set_capacity(disks[lo->lo_number], 0);
> + set_capacity(lo->lo_disk, 0);
> invalidate_bdev(bdev, 0);
> bd_set_size(bdev, 0);
> mapping_set_gfp_mask(mapping,
On 3/30/07, Ken Chen <[EMAIL PROTECTED]> wrote:
Remove artificial maximum 256 loop device that can be created due to a
legacy device number limit. Searching through lkml archive, there are
several instances where users complained about the artificial limit
that the loop driver
Thomas M
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 6b5b642..7db2c38 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -77,9 +77,8 @@ #include
#include
-static int max_loop = 8;
-static struct loop_device *lo
Thomas M
Signed-off-by: Ken Chen [EMAIL PROTECTED]
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 6b5b642..7db2c38 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -77,9 +77,8 @@ #include linux/kthread.h
#include asm/uaccess.h
-static int max_loop = 8;
-static
On 3/30/07, Ken Chen [EMAIL PROTECTED] wrote:
Remove artificial maximum 256 loop device that can be created due to a
legacy device number limit. Searching through lkml archive, there are
several instances where users complained about the artificial limit
that the loop driver impose
On 3/30/07, Jan Engelhardt [EMAIL PROTECTED] wrote:
lo-lo_device = NULL;
lo-lo_backing_file = NULL;
lo-lo_flags = 0;
- set_capacity(disks[lo-lo_number], 0);
+ set_capacity(lo-lo_disk, 0);
invalidate_bdev(bdev, 0);
bd_set_size(bdev, 0);
mapping_set_gfp_mask(mapping,
On 3/30/07, Andrew Morton [EMAIL PROTECTED] wrote:
So.. this change will cause a fatal error for anyone who is presently
using max_loop, won't it? If they're doing that within their
initramfs/initrd/etc then things could get rather ugly for them.
probably, if they access loop device
On 27 Mar 2007 17:01:01 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
What is the problem? You have cache misses on the the hash table
or are the instructions really an issue on a modern CPU?
It was page_to_pfn() on numa system. I think it's cache misses on per
node pgdat lookup with node
On 3/26/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
LTP's vmsplice01 triggers the below:
Unable to handle kernel NULL pointer dereference at 0130 RIP:
[] pipe_to_file+0x1f3/0x2a6
Ouch, generic_pipe_buf_map() and unmap is used by both pipe and
splice, I better constrain all
On 3/26/07, Andrew Morton [EMAIL PROTECTED] wrote:
LTP's vmsplice01 triggers the below:
Unable to handle kernel NULL pointer dereference at 0130 RIP:
[8029e1b6] pipe_to_file+0x1f3/0x2a6
Ouch, generic_pipe_buf_map() and unmap is used by both pipe and
splice, I better
On 27 Mar 2007 17:01:01 +0200, Andi Kleen [EMAIL PROTECTED] wrote:
What is the problem? You have cache misses on the the hash table
or are the instructions really an issue on a modern CPU?
It was page_to_pfn() on numa system. I think it's cache misses on per
node pgdat lookup with node index
On 3/23/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
@@ -1383,7 +1380,7 @@ int loop_unregister_transfer(int number)
xfer_funcs[n] = NULL;
- for (lo = _dev[0]; lo < _dev[max_loop]; lo++) {
+ list_for_each_entry(lo, _devices, lo_list) {
whole
block device, not a partition within another device. Otherwise, I
think it will cause a recursive mutex lock in block_dev.c:do_open().
This patch should fix the problem.
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
--- ./drivers/block/loop.c.orig 2007-03-24 17:05:51.0 -0700
+
On 3/23/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
a) Ken observes that obtaining private hugetlb memory via hugetlbfs
involves "fuss".
b) the libhugetlbfs maintainers then go off and implement a no-fuss way of
doing this.
Hmm, what started this thread was libhugetlbfs maintainer
On 3/23/07, Andrew Morton [EMAIL PROTECTED] wrote:
a) Ken observes that obtaining private hugetlb memory via hugetlbfs
involves fuss.
b) the libhugetlbfs maintainers then go off and implement a no-fuss way of
doing this.
Hmm, what started this thread was libhugetlbfs maintainer
block device, not a partition within another device. Otherwise, I
think it will cause a recursive mutex lock in block_dev.c:do_open().
This patch should fix the problem.
Signed-off-by: Ken Chen [EMAIL PROTECTED]
--- ./drivers/block/loop.c.orig 2007-03-24 17:05:51.0 -0700
+++ ./drivers
On 3/23/07, Jan Engelhardt [EMAIL PROTECTED] wrote:
@@ -1383,7 +1380,7 @@ int loop_unregister_transfer(int number)
xfer_funcs[n] = NULL;
- for (lo = loop_dev[0]; lo loop_dev[max_loop]; lo++) {
+ list_for_each_entry(lo, loop_devices, lo_list) {
On 3/23/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
I think you're fixing the symptom here and not the cause. If calculating
the virtual address of a page is so expensive on your setup it should
define WANT_PAGE_VIRTUAL and we should always cache the virtual address
in struct page.
vaddr to speed up pipe buffer
mapping functions.
There is another suboptimal block in pipe_read() where wake_up is
called twice. I think it was an oversight since in pipe_write(), it
looks like it is doing the right thing.
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
diff --git a/fs/pipe.c
On 3/23/07, Nish Aravamudan <[EMAIL PROTECTED]> wrote:
Comment needs updating too.
Thanks. How could I miss that :-(
updated patch:
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 8c718a3..981886f 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -734,7 +734,7
add a char device /dev/hugetlb that behaves similar to /dev/zero,
built on top of internal hugetlbfs mount.
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
diff -u b/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
--- b/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -795,6 +
rename hugetlb_zero_setup() to hugetlb_file_setup() to better match
function name convention like shmem implementation. Also add an
argument to the function to indicate whether file setup should reserve
hugetlb page upfront or not.
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
diff --gi
has more detail description for each changeset.
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Ple
On 3/23/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
On Fri, 23 Mar 2007, William Lee Irwin III wrote:
>> Lack of compiletesting beyond x86-64 in all probability.
On Fri, Mar 23, 2007 at 03:15:55PM +, Mel Gorman wrote:
> Ok, this will go kablamo on Power then even if it compiles. I
On 3/23/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
I like this patch a lot, though I'm not likely to get around to testing
it today. If userspace testcode is available that would be great to see
posted so I can just boot into things and run that.
Here is the test code that I used:
1 - 100 of 132 matches
Mail list logo
