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
---
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-
_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
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
t affect 32-bit 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_qu
load balance 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
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 t
variable below 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 l
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 real
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
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 al
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/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, l
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 commit w
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
un
mmit 07002e995638b83a6987180f43722a0eb39d4932
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: Li
mutex_lock(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 fo
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 node
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 usuall
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: s
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 c
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
ess iffy is the
right 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 als
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
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(&ring->head, head, head + 1));
A hasty grep indicates that only 14 out of 23 architectures implement
cmpxchg().
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 3
ze 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 &l
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.
il 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
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 non-seq
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 impose. Th
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
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/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 change
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) {
mutex_lo
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 compl
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. There's
e buffer page's kernel 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 PROTECTE
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 d
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:
(wa
ev/zero for
hugetlb page. So I coded it up on top of existing hugetlbfs. The
core change is really small and half of the patch is really just
moving things around. I think this at least can partially fulfill the
goal.
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
diff --git a/drivers/char/mem
hes kernel pipe buffer page's kernel 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 Ch
On 2/20/07, Ananiev, Leonid <[EMAIL PROTECTED]> wrote:
1) mem=1G in kernel boot param if you have more
2) unmount; mk2fs; mount
3) dd if=/dev/zero of= bs=1M count=1200
4) aiostress -s 1200m -O -o 2 -i 1 -r 16k
5) if i++<50 goto 2).
Would you please instrument the call chain of
invalidate_compl
clean up unneeded type cast by properly declare data type.
Signed-off-by: Ken Chen <[EMAIL PROTECTED]>
diff --git a/arch/i386/lib/bitops.c b/arch/i386/lib/bitops.c
index 97db385..afd0045 100644
--- a/arch/i386/lib/bitops.c
+++ b/arch/i386/lib/bitops.c
@@ -43,7 +43,7 @@ EXPORT_
On 2/16/07, Olaf Hering <[EMAIL PROTECTED]> wrote:
From: [EMAIL PROTECTED]
Un-Breaks pthreads, since Oct 2003.
why aren't you using /etc/security/limits.conf?
I think the stack limit can be set as big as 8TB on ia64 with default
16KB page size.
- Ken
-
To unsubscribe from this list: send the
On 2/12/07, Dave McCracken <[EMAIL PROTECTED]> wrote:
This patch enables the full functionality of truncate for hugetlbfs
files. Truncate was originally limited to reducing the file size
because page faults were not supported for hugetlbfs. Now that page
faults have been implemented it is now p
On 2/9/07, Ananiev, Leonid I <[EMAIL PROTECTED]> wrote:
I have used EIOCBRETRY in the patch to minimize source code modification
only.
[...]
A lot of errno's have different meaning in different functions or
contexts. EAGAIN could be used instated of EIOCBRETRY for irredundant
set.
I also think
On 2/1/07, Ananiev, Leonid I <[EMAIL PROTECTED]> wrote:
>> BUG: warning at mm/truncate.c:398/invalidate_inode_pages2_range()
> That warning got removed from -rc7.
2.6.20-rc-7: After 57 minutes and after 25 minutes of aiostress running
I've got 2 system hangs without any message in log.
On the t
On 1/29/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
But, never mind hugetlb, you still not quite convinced me that there's
no problem at all with get_user_pages find_extend_vma growing on ia64.
I repeat that ia64_do_page_fault has REGION tests to guard against
expanding either kind of stack acro
On 1/27/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
Thanks, that's reassuring for the hugetlb case, and therefore Adam's
patch should not be delayed. But it does leave open the question I
was raising in the text you've snipped: if ia64 needs those stringent
REGION checks in its ia64_do_page_faul
On 1/26/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
Less trivial (and I wonder whether you've come to this from an ia64
or a powerpc direction): I notice that ia64 has more stringent REGION
checks in its ia64_do_page_fault, before calling expand_stack or
expand_upwards. So on that path, the usua
Dmitriy Monakhov wrote on Jan 24, 11:00 pm
> Move common segments checks from __generic_file_aio_{read,write}_nolock()
> to separate helper function generic_segment_checks().WOW my eyes
I'm realy sorry but this patch is litle bit broken. :(
I've forgot to check generic_segment_checks() retu
66 matches
Mail list logo
