Hi Vegard,
On Nov 27, 2007 5:16 PM, Vegard Nossum [EMAIL PROTECTED] wrote:
+config KMEMCHECK
+ bool Trap use of uninitialized memory
+ depends on X86_32 !CC_OPTIMIZE_FOR_SIZE
+ help
+ This option enables tracing of dynamically allocated kernel memory
+ to
Hi Ingo,
On Dec 8, 2007 10:29 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
so it has a free list, which is clearly per cpu. Hang on! Isnt that
actually a per CPU queue? Which SLUB has not, we are told? The U in
SLUB. How on earth can an allocator in 2007 claim to have no queuing
(which is in
;
+
if (!c-page)
goto new_slab;
In case you didn't already merge this:
Reviewed-by: Pekka Enberg [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
Hi Ingo,
On Dec 9, 2007 10:50 AM, Ingo Molnar [EMAIL PROTECTED] wrote:
yes, i understand the initial announcement (and the Kconfig entry still
says the same), but that is not matched up by the reality i see in the
actual code - SLUB clearly uses a queue/list of objects (as cited in my
Hi Richard,
On Dec 10, 2007 9:29 PM, Richard Knutsson [EMAIL PROTECTED] wrote:
Remove local definition of TRUE/FALSE.
This is already fixed in Francois' tree:
http://git.kernel.org/?p=linux/kernel/git/romieu/netdev-2.6.git;a=commitdiff;h=2af61e99e3d1c959840ea007ff56b15db794fb99
Hi,
On Dec 10, 2007 11:31 PM, Jonathan Corbet [EMAIL PROTECTED] wrote:
I'm just getting around to looking at this. One thing jumped out at me:
+ if (bio-bi_throttle) {
+ struct request_queue *q = bio-bi_queue;
+ bio-bi_throttle = 0; /* or detect multiple endio
On Dec 24, 2007 9:12 PM, Christoph Lameter [EMAIL PROTECTED] wrote:
Hmmm... What is the combination of config variables that causes this? I
moved the count_partial function in mm in order to make the merge of slab
defrag easier.
I think it's CONFIG_PROC_FS without CONFIG_SYSFS.
--
To
]
---
To minimize ifdeffery, this leaves it with S_IWUSR though unwritable:
I'm assuming that's acceptable.
I already sent the remaining bits to Linus but this looks much
cleaner. Thanks Hugh!
Acked-by: Pekka Enberg [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
), and
then both SLAB and SLUB just have the exact same interfaces.
Which means that SLOB could also trivially implement the same thing, with
no new #ifdef'fery or other crud.
It's totally untested, but looks fairly obvious.
Looks good to me. Thanks! :-)
Reviewed-by: Pekka Enberg [EMAIL PROTECTED
Hi Arjan,
On Jan 3, 2008 2:56 AM, Arjan van de Ven [EMAIL PROTECTED] wrote:
+int do_warn_on(const unsigned long condition, const char *file,
+ const int line, const char *function)
+{
+ if (unlikely(condition)) {
+ printk(KERN_WARNING WARNING: at
Hi Andi,
On Jan 4, 2008 4:39 PM, Andi Kleen [EMAIL PROTECTED] wrote:
The kernel process request that _all_ contributors run their patches
through checkpath.pl and fix the problems.
That's new. When and by whom was that rule been introduced? And with what
rationale?
Not be new to anyone
Hi Hugh,
On 10/25/07, Hugh Dickins [EMAIL PROTECTED] wrote:
--- 2.6.24-rc1/mm/shmem.c 2007-10-24 07:16:04.0 +0100
+++ linux/mm/shmem.c2007-10-24 22:31:09.0 +0100
@@ -915,6 +915,21 @@ static int shmem_writepage(struct page *
struct inode *inode;
-proof this code against whatever stacking
filesystems come along.
Heh, what can I say, after several readings, I still find your above
explanation (which I totally agree with) more to the point than the
actual comment :-).
In any case, the patch looks good to me.
Reviewed-by: Pekka Enberg [EMAIL
Hi,
On 10/25/07, Linus Torvalds [EMAIL PROTECTED] wrote:
I think the OpenBSD people decided to actually do something about this,
and I suspect it had *nothing* to do with license issues, and everything
to do with these kinds of problems. I wish them all the luck, although
personally I think
Hi,
On 10/26/07, Neil Brown [EMAIL PROTECTED] wrote:
It seems that the new requirement is that if the address_space
chooses not to write out the page, it should now call SetPageActive().
If that is the case, I think it should be explicit in the
documentation - please?
Agreed.
-
To
Hi Hugh,
On 10/25/07, Hugh Dickins [EMAIL PROTECTED] wrote:
@@ -349,10 +349,6 @@ static pageout_t pageout(struct page *pa
res = mapping-a_ops-writepage(page, wbc);
if (res 0)
handle_write_error(mapping, page, res);
- if
, Pekka Enberg [EMAIL PROTECTED] wrote:
Needs more work to fix problems raised by viro. I am cooking up a
patch but it won't be ready for 2.6.24.
FYI the patches (with known bugs) can be found here in case anyone is
interested:
http://www.kernel.org/pub/linux/kernel/people/penberg/patches/revoke
Hi,
On 10/24/07, Matthew Wilcox [EMAIL PROTECTED] wrote:
+static void sb_vprintf(struct stringbuf *sb, const char *format, va_list
args)
+{
+ char *s;
+ int size;
+
+ if (sb-alloc == -ENOMEM)
+ return;
+ if (sb-alloc == 0) {
+ sb-s =
Hi,
The current Linus' git does not compile on i386 for UM defconfig:
CC init/do_mounts.o
In file included from init/do_mounts.c:19:
init/do_mounts.h: In function 'bstat':
init/do_mounts.h:25: error: storage size of 'stat' isn't known
init/do_mounts.h:25: warning: unused variable 'stat'
Hi Rusty,
On 10/26/07, Rusty Russell [EMAIL PROTECTED] wrote:
This just seems like more optimization and complexity that we need.
Interfaces
using vsnprintf don't seem like good candidates for optimization.
How about this? It's as simple as I could make it...
FWIW I like this
Hi Rusty,
On Saturday 27 October 2007 21:47:09 Pekka Enberg wrote:
+ kfree(oldsb);
+ *sb = (struct stringbuf *)enomem_string;
Why don't we just return -ENOMEM here just like all other APIs in the
kernel?
On 10/27/07, Rusty Russell [EMAIL PROTECTED] wrote
Hi,
On 10/29/07, Christoph Lameter [EMAIL PROTECTED] wrote:
We don't need preempt_enable for CONFIG_SMP, right?
preempt_enable is needed if preemption is enabled.
Disabled? But yeah, I see that slab_trylock() can leave preemption
disabled if cmpxchg fails. Was confused by the #ifdefs... :-)
Hi,
On 10/22/07, Rik van Riel [EMAIL PROTECTED] wrote:
BUG() will terminate the process that runs into it, so you can
just remove the return alltogether. If BUG() is hit, the return
will never be reached.
This isn't true when CONFIG_BUG is disabled (in embedded builds, for example).
Hi Roel,
On 10/22/07, Roel Kluin [EMAIL PROTECTED] wrote:
diff --git a/mm/slab.c b/mm/slab.c
index cfa6be4..20c58dc 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1606,8 +1606,10 @@ void __init kmem_cache_init(void)
struct kmem_cache *cachep;
Hi Alexey,
On 10/22/07, Alexey Dobriyan [EMAIL PROTECTED] wrote:
printing eip: f881b9f3 *pdpt = 3001 1*pde = 0480a067
*pte =
--- a/arch/x86/mm/fault_32.c
+++ b/arch/x86/mm/fault_32.c
@@ -550,7 +550,7 @@ no_context:
page =
Hi Rik,
On 10/22/07, Rik van Riel [EMAIL PROTECTED] wrote:
On Mon, 22 Oct 2007 12:30:00 +0300
I guess people who disable CONFIG_BUG really choose to shoot themselves
in the foot when something bad happens. The kernel is full of error
paths where the current thread really should not be
Hi Hugh,
On 10/22/07, Hugh Dickins [EMAIL PROTECTED] wrote:
I don't disagree with your unionfs_writepages patch, Pekka, but I think
it should be viewed as an optimization (don't waste time trying to write
a group of pages when we know that nothing will be done) rather than as
essential.
Ok,
Hi Hugh,
On Mon, 15 Oct 2007, Pekka Enberg wrote:
I wonder whether _not setting_ BDI_CAP_NO_WRITEBACK implies that
-writepage() will never return AOP_WRITEPAGE_ACTIVATE for
!wbc-for_reclaim case which would explain why we haven't hit this bug
before. Hugh, Andrew?
On 10/22/07, Hugh
.
Acked-by: Yasunori Goto [EMAIL PROTECTED]
Reviewed-by: Pekka Enberg [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
Please read the FAQ
Hi,
On Tue, 23 Oct 2007, Alexey Dobriyan wrote:
cc1 invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
Christoph Lameter wrote:
Regular Order 0 alloc but why is there no memory available ,
reclaimed?
I am too wondering where all that memory is going. Logging /proc/meminfo
Hi,
On Tue, 23 Oct 2007, Alexey Dobriyan wrote:
With SLAB this workload never went to OOM killer.
With SLUB and pretty much all debugging enabled, it finishes to the end
(albeit slowly).
With SLUB and no debugging, OOM killer kicks in.
On 10/23/07, Christoph Lameter [EMAIL PROTECTED]
Hi Christoph,
(I fixed linux-mm cc to kvack.org.)
On 10/23/07, Christoph Lameter [EMAIL PROTECTED] wrote:
The number of objects per page is reduced by enabling full debugging. That
triggers a potential of more order 1 allocations but we are failing at
order 0 allocs.
Yeah, but we're _not
On Feb 9, 2008 5:13 PM, Christer Weinigel [EMAIL PROTECTED] wrote:
But lets say that the b-tree code uses Linux-only primitives such as
kmalloc or spinlocks, and that I wrote the code specifically for the
Linux kernel, does that make it into a derivative work?
What if I do a trivial replace
On Feb 9, 2008 6:50 PM, Christer Weinigel [EMAIL PROTECTED] wrote:
A device driver isn't that hard either. I can write a device driver
with a hand tied behind my back, to write a good balancing tree, I'd
have to spend a lot more time reading up on algorithms. So trivial is
a matter of
Hi Pekka,
On Feb 9, 2008 8:23 PM, Pekka Paalanen [EMAIL PROTECTED] wrote:
By default it reserves 32 MB/cpu of relay buffers during module init.
It's this big based on experimentation with the nvidia proprietary driver.
There is no other way than unloading the module to free the buffers, or
Hi,
On Feb 9, 2008 9:11 PM, Pekka Paalanen [EMAIL PROTECTED] wrote:
No difference. I just have to do it at some point. I can't work on this
every day and when it comes to kernel, I'm a complete newbie. So things
will take time. If people want that I fix this before mmiotrace goes into
On Feb 10, 2008 7:05 PM, Greg KH [EMAIL PROTECTED] wrote:
No, this is a different CVE, as it is a different problem from the
original 09 and 10 report.
It has been given CVE-2008-0600 to address this issue (09 and 10 only
affect .23 and .24 kernels, and have been fixed.)
+
Jeff Dike wrote:
UML defined its own external __kmalloc and things. Isnt there some other
way to fix it? I guess including slab.h is not possible here?
It would be an annoyance to reintroduce um_kmalloc, but that might be
the best thing to do here.
I'm ok with that as long as we get this
Hi Daniel,
On Feb 11, 2008 9:29 AM, Daniel Phillips [EMAIL PROTECTED] wrote:
I think many users would first go to kernel.org on a day like today, as
I did. Nothing to see there. We could do a way better job of getting
the word out.
Any suggestions what I could have done better here? As soon
and the redundant declarations should
be removed. Andrew, please queue up this patch.
Reviewed-by: Pekka Enberg [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
*addr)
return (unsigned long)addr PAGE_MAPPING_ANON;
}
-void *slab_address(struct page *page)
+static void *slab_address(struct page *page)
{
return page-end - PAGE_MAPPING_ANON;
}
Acked-by: Pekka Enberg [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line
Hi Nishanth,
On Thu, Feb 14, 2008 at 7:38 PM, Nishanth Aravamudan [EMAIL PROTECTED] wrote:
Is it just me, or does
((user_addr + iov[seg].iov_len + PAGE_SIZE - 1)/PAGE_SIZE -
user_addr/PAGE_SIZE)
not simplify to
= ((iov[seg].iov_len + PAGE_SIZE - 1)/PAGE_SIZE +
PROTECTED]
Looks good to me.
Reviewed-by: Pekka Enberg [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
Please read the FAQ at http
Hi,
Vegard Nossum wrote:
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 412672a..7bdb37f 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1294,7 +1294,11 @@ static inline void __skb_queue_purge(struct
sk_buff_head *list)
static inline struct sk_buff
Vegard Nossum wrote:
+DEFINE_PER_CPU(bool, kmemcheck_busy) = false;
+DEFINE_PER_CPU(uint32_t, kmemcheck_addr1) = 0;
+DEFINE_PER_CPU(uint32_t, kmemcheck_addr2) = 0;
+DEFINE_PER_CPU(uint32_t, kmemcheck_reg_flags) = 0;
+
+DEFINE_PER_CPU(int, kmemcheck_num) = 0;
+DEFINE_PER_CPU(int,
On 10/22/2012 04:04 PM, Ezequiel Garcia wrote:
When freeing objects, the slob allocator currently free empty pages
calling __free_pages(). However, page-size kmallocs are disposed
using put_page() instead.
It makes no sense to call put_page() for kernel pages that are provided
by the object
On Fri, Oct 19, 2012 at 1:41 AM, Ezequiel Garcia elezegar...@gmail.com wrote:
This field was being used to store size allocation so it could be
retrieved by ksize(). However, it is a bad practice to not mark a page
as a slab page and then use fields for special purposes.
There is no need to
Hi Ezequiel,
On Thu, Sep 27, 2012 at 8:49 AM, tip-bot for Ezequiel Garcia
elezegar...@gmail.com wrote:
Commit-ID: 8781915ad2716adcd8cd5cc52cee791fc8b00fdf
Gitweb: http://git.kernel.org/tip/8781915ad2716adcd8cd5cc52cee791fc8b00fdf
Author: Ezequiel Garcia elezegar...@gmail.com
On Wed, Oct 24, 2012 at 12:43 PM, Lai Jiangshan la...@cn.fujitsu.com wrote:
SLUB only fucus on the nodes which has normal memory, so ignore the other
node's hot-adding and hot-removing.
Aka: if some memroy of a node(which has no onlined memory) is online,
but this new memory onlined is not
On Fri, 5 Oct 2012, Christoph Lameter wrote:
On Fri, 5 Oct 2012, Arnd Bergmann wrote:
Without this patch, building ARM collie_defconfig results in:
mm/slob.c: In function '__kmalloc_node':
mm/slob.c:431:152: warning: comparison of distinct pointer types lacks a
cast [enabled by
On Thu, 25 Oct 2012, Kirill A. Shutemov wrote:
vec is 0x in virtio_pci__specific_io_out() on crash.
Let's add proper bounds checking there. It doesn't not solves the issue
with booting crashkernel, but fix lkvm crash.
There's no sign-off for the patch. Kirill, care to update the patch
on 5c5e3b33b7cb959a401f823707bee006caadd76e, but fix
case were align sizeof(unsigned long long).
Signed-off-by: Matthieu Castet matthieu.cas...@parrot.com
CC: Russell King r...@arm.linux.org.uk
CC: Pekka Enberg penb...@cs.helsinki.fi
---
mm/slab.c |8 +++-
1 file changed, 3 insertions
kmalloc caches. So the same path that
led to nesting between kmalloc caches will could then lead to in-memcg
nesting. Because they are not annotated, lockdep will trigger.
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Christoph Lameter c...@linux.com
CC: Pekka Enberg penb
high-order (greater than 0) page allocation are very likely to
fail.
For more information on zsmalloc and its internals, read the
documentation at the top of the zsmalloc.c file.
Signed-off-by: Minchan Kim minc...@kernel.org
Acked-by: Pekka Enberg penb...@kernel.org
--
To unsubscribe from
-by: Minchan Kim minc...@kernel.org
Acked-by: Pekka Enberg penb...@kernel.org
--
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
On Fri, Nov 2, 2012 at 2:04 AM, Andrew Morton a...@linux-foundation.org wrote:
One thing:
Numbers can be found at https://lkml.org/lkml/2012/9/13/239
You claim in the above that the fork worload is 'slab intensive. Or
at least, you seem to - it's a bit fuzzy.
But how slab intensive is it,
On 09/24/2012 05:56 PM, Christoph Lameter wrote:
On Mon, 24 Sep 2012, Glauber Costa wrote:
The reason I say it is orthogonal, is that people will still want to see
their caches in /proc/slabinfo, regardless of wherever else they'll be.
It was a requirement from Pekka in one of the first times
and strndup_user.
Cc: Pekka Enberg penb...@kernel.org
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
mm/util.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/mm/util.c b/mm/util.c
index dc3036c..48d3ff8b 100644
--- a/mm/util.c
+++ b/mm/util.c
On Mon, Sep 24, 2012 at 8:13 PM, Ezequiel Garcia elezegar...@gmail.com wrote:
Will you pick this (and the rest of cleanup patches)
for v3.7 pull request?
Or is there anything for me to redo?
I merged all the patches except for the last one which conflicts with
the kmem/memcg changes.
--
To
On Wed, Sep 26, 2012 at 11:50 AM, Minchan Kim minc...@kernel.org wrote:
lib/Kconfig |2 +
lib/Makefile |1 +
lib/zsmalloc/Kconfig | 18 +
lib/zsmalloc/Makefile|1 +
portable. In addition, many embedded
product uses zram in real practive so I think there is no reason
to prevent promotion now.
Cc: Seth Jennings sjenn...@linux.vnet.ibm.com
Cc: Nitin Gupta ngu...@vflare.org
Signed-off-by: Minchan Kim minc...@kernel.org
FWIW,
Acked-by: Pekka Enberg penb
Hi Stephen,
On Wed, Oct 3, 2012 at 8:29 AM, Stephen Rothwell s...@canb.auug.org.au wrote:
Well, here we are at another merge window and the kvmtool tree is still
not merged. So, is it likely that it will be merged in this merge
window? or the next? If not, can I please remove it from
Lespinasse (1):
slab: do not call compound_head() in page_get_cache()
Pekka Enberg (6):
Revert mm/slab_common.c: cleanup
Revert mm/sl[aou]b: Move sysfs_slab_add to common
Revert mm/slab: Fix kmem_cache_alloc_node_trace() declaration
Merge branch 'slab/next' into slab
On Wed, Nov 7, 2012 at 1:21 PM, Kirill A. Shutemov kir...@shutemov.name wrote:
While the new API is very simple, it is still extensible (i.e. versioned).
Sorry, I didn't follow previous discussion on this, but could you
explain what's wrong with memory notifications from memcg?
As I can see
now;
- Pekka Enberg didn't like the complex attributes matching code, and
so it is no longer there;
- Nobody liked the raw vmstat attributes, and so they were eliminated
too.
I love the API and implementation simplifications but I hate the new
ABI. It's a specialized, single-purpose syscall
On Wed, Nov 7, 2012 at 1:30 PM, Pekka Enberg penb...@kernel.org wrote:
I love the API and implementation simplifications but I hate the new
ABI. It's a specialized, single-purpose syscall and bunch of procfs
tunables and I don't see how it's 'extensible' to anything but VM
s/anything but VM
Hi Greg,
On 11/7/12 7:20 PM, Greg Thelen wrote:
Related question: are there plans to extend this system call to
provide per-cgroup vm pressure notification?
Yes, that's something that needs to be addressed before we can ever
consider merging something like this to mainline. We probably need
On Thu, 16 Aug 2012, Joonsoo Kim wrote:
When we try to free object, there is some of case that we need
to take a node lock. This is the necessary step for preventing a race.
After taking a lock, then we try to cmpxchg_double_slab().
But, there is a possible scenario that cmpxchg_double_slab()
On Sat, 20 Oct 2012, Borislav Petkov wrote:
Add a rule to the kvm tool Makefile to build .asm versions of the files.
This is good for debugging purposes.
Cc: Pekka Enberg penb...@kernel.org
Cc: Sasha Levin levinsasha...@gmail.com
Cc: Asias He asias.he...@gmail.com
Signed-off-by: Borislav
On Sun, Oct 21, 2012 at 2:59 PM, Ingo Molnar mi...@kernel.org wrote:
You are wrong on three counts:
- As I mentioned it in my first mail to you this is not the
same as 'vm run': you still have a qemu-root.img while
tools/kvm does not ...
'vm run' works without having any disk
this. But after this first step, this can be done
easier.
Signed-off-by: Glauber Costa glom...@parallels.com
Acked-by: Christoph Lameter c...@linux.com
CC: Pekka Enberg penb...@cs.helsinki.fi
CC: David Rientjes rient...@google.com
I've applied patches 1-3. Thanks, Glauber!
--
To unsubscribe
On Mon, Oct 22, 2012 at 11:40 AM, Glauber Costa glom...@parallels.com wrote:
On 10/19/2012 11:34 PM, Christoph Lameter wrote:
On Fri, 19 Oct 2012, Glauber Costa wrote:
I, however, see no reason why we need to do so, since we are now locked
during the whole deletion (which wasn't necessarily
On Sat, Oct 20, 2012 at 6:48 PM, Joonsoo Kim js1...@gmail.com wrote:
kmalloc() and kmalloc_node() is always inlined into generic code.
However, there is a mistake in implemention of the SLUB.
In kmalloc() and kmalloc_node() of the SLUB,
we try to compare kmalloc_caches[index] with NULL.
As
On Mon, Oct 22, 2012 at 5:05 PM, Glauber Costa glom...@parallels.com wrote:
+/**
+ * kmem_cache_free - Deallocate an object
+ * @cachep: The cache the allocation was from.
+ * @objp: The previously allocated object.
+ *
+ * Free an object which was previously allocated from this
+ * cache.
On Mon, Oct 22, 2012 at 5:05 PM, Glauber Costa glom...@parallels.com wrote:
+/**
+ * kmem_cache_free - Deallocate an object
+ * @cachep: The cache the allocation was from.
+ * @objp: The previously allocated object.
+ *
+ * Free an object which was previously allocated from this
+ * cache.
the doubleword area.
The naming used by slab, slab_cache, is less confusing, and it is
preferred over slub's generic slab.
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Christoph Lameter c...@linux.com
CC: Pekka Enberg penb...@kernel.org
CC: David Rientjes rient...@google.com
Applied, thanks
On Mon, 22 Oct 2012, Anton Vorontsov wrote:
This patch introduces VMEVENT_ATTR_PRESSURE, the attribute reports Linux
virtual memory management pressure. There are three discrete levels:
VMEVENT_PRESSURE_LOW: Notifies that the system is reclaiming memory for
new allocations. Monitoring
in this patch
itself.
Signed-off-by: Glauber Costa glom...@parallels.com
CC: Joonsoo Kim js1...@gmail.com
CC: David Rientjes rient...@google.com
CC: Pekka Enberg penb...@kernel.org
CC: Christoph Lameter c...@linux.com
So I hate this patch with a passion. We don't have any fastpaths in
mm
On Mon, Oct 8, 2012 at 10:26 AM, Jiri Kosina jkos...@suse.cz wrote:
Commit 1331e7a1bbe1 (rcu: Remove _rcu_barrier() dependency on
__stop_machine()) introduced slab_mutex - cpu_hotplug.lock dependency
through kmem_cache_destroy() - rcu_barrier() - _rcu_barrier() -
get_online_cpus().
Lockdep
Hi Linus,
Please pull the latest SLAB tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git slab/urgent
It contains a lockdep false positive fix from Jiri Kosina I missed from
the previous pull request.
Pekka
--
The following
Hi Anton,
On Thu, Oct 4, 2012 at 1:20 PM, Anton Vorontsov
anton.voront...@linaro.org wrote:
Hello Pekka,
Just a few updates to vmevents:
- Some cleanups and refactorings -- needed for easier integration of
'memory pressure' work;
- Forward to newer Linus' tree, fix conflicts.
Applied,
On Thu, Oct 4, 2012 at 1:21 PM, Anton Vorontsov
anton.voront...@linaro.org wrote:
Soon we'll use this new function for other code; plus this makes code less
indented.
Signed-off-by: Anton Vorontsov anton.voront...@linaro.org
---
mm/vmevent.c | 107
On Fri, Sep 14, 2012 at 10:15 PM, Marcin Slusarz
marcin.slus...@gmail.com wrote:
[3.017200] [ cut here ]
[3.017203] [ cut here ]
[3.017208] WARNING: at arch/x86/mm/kmemcheck/kmemcheck.c:634
kmemcheck_fault+0xb9/0xd0()
this is
On Thu, Oct 25, 2012 at 9:40 AM, Minchan Kim minc...@kernel.org wrote:
Your description doesn't include why we need new vmevent_fd(2).
Of course, it's very flexible and potential to add new VM knob easily but
the thing we is about to use now is only VMEVENT_ATTR_PRESSURE.
Is there any other
On Wed, Oct 24, 2012 at 6:27 PM, Kirill A. Shutemov
kirill.shute...@linux.intel.com wrote:
Hi,
I've tried to play with kexec using lkvm. Unfortunately, lkvm crashes when
I try to switch to crashkernel.
I use Linus tree + penberg/kvmtool/next + one x86 mm patch[1].
Kernel is defconfig +
On Thu, 25 Oct 2012, Sasha Levin wrote:
I think we're seeing that because we don't handle VIRTIO_MSI_NO_VECTOR
properly.
We need to deal with the ability to remove GSI friends as well. I've
added it to my workqueue (unless someone deals with it first).
Any reason I shouldn't apply
of specifying --gtk option on command line (unless other related
options are not given).
$ cat ~/.perfconfig
[gtk]
report = true
Cc: Pekka Enberg penb...@kernel.org
Signed-off-by: Namhyung Kim namhy...@kernel.org
Acked-by: Pekka Enberg penb...@kernel.org
--
To unsubscribe from this list: send
Hi Avleen,
On Tue, Oct 16, 2012 at 8:51 PM, Avleen Vig avl...@gmail.com wrote:
I *think* this is the right place to ask this, and apologies if it's not
(is there a better place?).
We have checks which read /proc/slabinfo once a minute, and have noticed
that this causes the entire system to
On Thu, 18 Oct 2012, Ingo Molnar wrote:
* Christoph Hellwig h...@infradead.org wrote:
On Fri, Oct 12, 2012 at 02:34:33PM +0300, Pekka Enberg wrote:
Hi Linus,
Please consider pulling the latest LKVM tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git
Hi Andy,
On 9/28/07, Andy Whitcroft [EMAIL PROTECTED] wrote:
That is unfair. Every time we discuss it I state that I disagree that
hiding mostly useful tests is a good thing. I would love the tests to
be 100% accurate, but if I removed all the tests that can false positive
I would literally
Hi Neil,
On 9/30/07, Neil Romig [EMAIL PROTECTED] wrote:
I would suspect a memory problem but memtest86+ gives no errors despite
numerous
passes, and I get no errors in older kernels. Does anyone have any idea what
changed in
2.6.18 to cause such an error?
I don't but you can try to
On 10/2/07, Andrew Morton [EMAIL PROTECTED] wrote:
revoke-special-mmap-handling.patch
revoke-special-mmap-handling-vs-fault-vs-invalidate.patch
revoke-core-code.patch
slab-api-remove-useless-ctor-parameter-and-reorder-parameters-vs-revoke.patch
revoke-support-for-ext2-and-ext3.patch
Hi Neil,
On 10/3/07, Neil Romig [EMAIL PROTECTED] wrote:
Thanks for your help on this. I have narrowed it down to commit
c22ce143d15eb288543fe9873e1c5ac1c01b69a1 x86: cache pollution aware
__copy_from_user_ll(). This fits with the errors I'm getting, so now I need
to find out if I can safely
Hi Neil,
On 10/3/07, Neil Romig [EMAIL PROTECTED] wrote:
Thanks for your help on this. I have narrowed it down to commit
c22ce143d15eb288543fe9873e1c5ac1c01b69a1 x86: cache pollution aware
__copy_from_user_ll(). This fits with the errors I'm getting, so now I
need
to find out if I
Hi Linus,
On 10/3/07, Linus Torvalds [EMAIL PROTECTED] wrote:
I would bet that the reason the intel-optimized memcpy triggers this is
that the non-temporal stores just means that you go out directly on the
bus, and it probably just shows a weakness in the chipset or bus that
doesn't show with
Hi Kamalesh,
On 10/4/07, Kamalesh Babulal [EMAIL PROTECTED] wrote:
Kernel bug hit, while running fsstress over the CIFS mounted partition on
the ppc64 machine
cpu 0x0: Vector: 700 (Program Check) at [c00106ec75f0]
pc: c00d69cc: .kmem_cache_free+0xac/0x154
lr:
Hi,
On 10/5/07, Jens Axboe [EMAIL PROTECTED] wrote:
I'd like to second Davids emails here, this is a serious problem. Having
a reproducible test case lowers the barrier for getting the problem
fixed by orders of magnitude. It's the difference between the problem
getting fixed in a day or two
Hi Ryan,
On 10/8/07, Ryan Finnie [EMAIL PROTECTED] wrote:
Doesn't appear to be enough. I can't figure out why (since it appears
write_cache_pages bubbles up directly to sys_msync), but with that
patch applied, in my test case[1], msync returns -1 EIO. However,
with the exact same kernel
Hi Jonathan,
On 10/8/07, Jonathan Corbet [EMAIL PROTECTED] wrote:
As I was trying to sleep last night, it occurred to me that what we
might need is an equivalent of the DCO for the Reviewed-by tag. To that
end, I dedicated a few minutes of my life to the following bit of text.
It's really
Hi,
On 10/9/07, Grosjo.net - jom [EMAIL PROTECTED] wrote:
Would it be possible to include the patches (available on www.synce.org)
for WindowsMobile5, as most mobile phones are under Window$, and it is
very convenient to connect it to the laptop under Linux
Sounds useful so please ask the
101 - 200 of 1778 matches
Mail list logo