On Mon, 2005-08-08 at 11:32 -0700, Zach Brown wrote:
Sorry if this is an obvious question but what prevents another thread
from doing mmap() before we do the second walk and messing up num_gh?
Nothing, I suspect. OCFS2 has a problem like this, too. It wants a way
for a file system to
On 12/19/06, Andrew Morton [EMAIL PROTECTED] wrote:
Wow. I didn't expect that, because Mark Haber reported that ext3's
data=writeback
fixed it. Maybe he didn't run it for long enough?
I don't think it did fix it for Mark:
http://marc.theaimsgroup.com/?l=linux-kernelm=116625777306843w=2
-
On 12/20/06, Sébastien Dugué [EMAIL PROTECTED] wrote:
set_param_str() cannot use kstrdup() to duplicate the parameter. That's
fine when the driver is compiled as a module but it sure is not when
built into the kernel as the kernel parameters are parsed before the
kmalloc slabs are setup.
On 1/10/07, Serge E. Hallyn [EMAIL PROTECTED] wrote:
But since it looks like you just munmap the region now, shouldn't a
subsequent munmap by the app just return -EINVAL? that seems appropriate
to me.
Applications don't know about revoke and neither should they.
Therefore close(2) and
Hi Joe,
On 1/12/07, joe jin [EMAIL PROTECTED] wrote:
@@ -788,7 +786,7 @@ static int rlb_initialize(struct bonding
spin_lock_init((bond_info-rx_hashtbl_lock));
- new_hashtbl = kmalloc(size, GFP_KERNEL);
+ new_hashtbl = kzalloc(size, GFP_KERNEL);
if (!new_hashtbl) {
On 1/11/07, Serge E. Hallyn [EMAIL PROTECTED] wrote:
Right, but is returning -EINVAL to userspace on munmap a problem?
Yes, because an application has no way of reusing the revoked mapping
range. The current patch should get this right, though.
On 1/11/07, Serge E. Hallyn [EMAIL PROTECTED]
Hi Andrew,
On 1/9/07, Pekka J Enberg [EMAIL PROTECTED] wrote:
From: Pekka Enberg [EMAIL PROTECTED]
The current implementation of cache_grow() has to either (1) use pre-allocated
memory for the slab or (2) allocate the memory itself which makes the error
paths messy. Move __GFP_NO_GROW
On 1/10/07, Serge E. Hallyn [EMAIL PROTECTED] wrote:
Now, what slim needs isn't revoke all files for this inode,
but revoke this task's write access to this fd. So two functions
which could be useful are
int fd_revoke_write(struct task_struct *tsk, int fd)
int
On 1/18/07, Michael Halcrow [EMAIL PROTECTED] wrote:
+ page_data = (char *)kmap_atomic(page, KM_USER0);
+ lower_page_data = (char *)kmap_atomic(lower_page, KM_USER1);
Drop 'em redundant casts, please.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On 1/19/07, Robert P. J. Day [EMAIL PROTECTED] wrote:
is there a simple explanation for how to *properly* define inline
routines in the kernel? and maybe this can be added to the
CodingStyle guide (he mused, wistfully).
AFAIK __always_inline is the only reliable way to force inlining where
it
On 12/8/06, Ulrich Windl [EMAIL PROTECTED] wrote:
my apologies for disobeying all the rules for submitting patches, but I'll
suggest
a performance optimization for strstrip() in lib/string.c:
Makes sense. Please submit a patch.
-
To unsubscribe from this list: send the line unsubscribe
On 12/9/06, Robert P. J. Day [EMAIL PROTECTED] wrote:
perhaps i'm just being clueless about the authorship protocol here,
but i'm a bit hacked off by noticing that at least one submitted patch
of mine was apparently re-submitted (albeit slightly modified) a few
days later by another poster and
On 12/9/06, Robert P. J. Day [EMAIL PROTECTED] wrote:
@@ -705,7 +705,7 @@ static int uss720_probe(struct usb_inter
/*
* Allocate parport interface
*/
- if (!(priv = kcalloc(sizeof(struct parport_uss720_private), 1,
GFP_KERNEL))) {
+ if (!(priv = kcalloc(1,
On 12/9/06, Pekka Enberg [EMAIL PROTECTED] wrote:
You really ought to send these cleanups to [EMAIL PROTECTED] with LKML
cc'd to get them merged.
...or even better, the relevant maintainer.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Hi Christoph,
On 12/8/06, Christoph Lameter [EMAIL PROTECTED] wrote:
+#defineSLAB_POISON 0x0800UL/* DEBUG: Poison
objects */
+#defineSLAB_HWCACHE_ALIGN 0x2000UL/* Align objs on cache
lines */
+#define SLAB_CACHE_DMA 0x4000UL/*
On 12/9/06, Robert P. J. Day [EMAIL PROTECTED] wrote:
argh, in that i've already mentioned that, following the guidelines in
SubmittingPatches, i prefer that each of my patches have one logical
purpose. once the order of the kcalloc() args is corrected, that
would be followed by a single
On 12/9/06, Robert P. J. Day [EMAIL PROTECTED] wrote:
normally what i would do but, in the case of that patch, there are
five files affected, *all* of which are in totally different
subsystems (macintosh, net, scsi, usb, sunrpc). are you suggesting
that up to 5 different people be CC'ed?
and
On 12/9/06, Robert P. J. Day [EMAIL PROTECTED] wrote:
no. those two submissions represent two logically different fixes
and i have no intention of combining them.
Like I said, fixing the order of kcalloc parameters with a follow-up
patch to use kzalloc is just plain stupid. You can ignore my
On 12/12/06, Yan Burman [EMAIL PROTECTED] wrote:
size = txdr-count * sizeof(struct e1000_buffer);
- if (!(txdr-buffer_info = kmalloc(size, GFP_KERNEL))) {
+ if (!(txdr-buffer_info = kzalloc(size, GFP_KERNEL))) {
ret_val = 1;
goto err_nomem;
On 9/5/05, Howard Chu [EMAIL PROTECTED] wrote:
So, any guesses why with otherwise identical config options, a kernel
with SMP enabled doesn't boot up with all of the device nodes that it
should? (Both drives are on the same controller. I haven't checked to
see if any other device files are
On 9/6/05, Richard Purdie [EMAIL PROTECTED] wrote:
+/*
+ * Corgi/Spitz Touchscreen to LCD interface
+ */
+unsigned long inline corgi_get_hsync_len(void)
+{
+ if (machine_is_corgi() || machine_is_shepherd() ||
machine_is_husky()) {
+#ifdef CONFIG_PXA_SHARP_C7xx
+
;
+}
On 9/6/05, Pekka Enberg [EMAIL PROTECTED] wrote:
Please consider making two version of corgi_get_hsync_len() instead
for both config options. The above is hard to read.
Uhm, forget it. I didn't realize both config options can be enabled at
the same time. Sorry for the noise
On 9/5/05, OGAWA Hirofumi [EMAIL PROTECTED] wrote:
But sorry, I have no time for reviewing all of patch now. I'll send it
to Andrew after review.
Ok. Please do the appropriate renaming also. Thanks.
Pekka
-
To unsubscribe from this list: send the line
On 9/7/05, Miloslav Trmac [EMAIL PROTECTED] wrote:
+static int __init map_bios(void)
+{
+ static const unsigned char __initdata signature[]
+ = { 0x42, 0x21, 0x55, 0x30 };
+
+ void __iomem *base;
+ size_t offset;
+ uint32_t entry_point;
+
+ base =
On 9/9/05, Anton Altaparmakov [EMAIL PROTECTED] wrote:
-static inline void *ntfs_malloc_nofs(unsigned long size)
+static inline void *__ntfs_malloc(unsigned long size,
+ unsigned int __nocast gfp_mask)
{
if (likely(size = PAGE_SIZE)) {
BUG_ON(!size);
On Wed, Sep 5, 2012 at 1:02 AM, Pekka Enberg penb...@kernel.org wrote:
How significant is the speed gain? The isa_done flag makes code flow
more difficult to follow.
On Wed, 5 Sep 2012, Yinghai Lu wrote:
Not really much.
when booting system:
memmap=16m$128m memmap=16m$512m memmap=16m
irina.tir...@intel.com
Reviewed-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 at http
On Fri, Sep 7, 2012 at 1:29 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
On Thu, Sep 06, 2012 at 11:05:11AM +0800, Michael Wang wrote:
On 09/05/2012 09:55 PM, Christoph Lameter wrote:
On Wed, 5 Sep 2012, Michael Wang wrote:
Since the cachep and cachep-slabp_cache's l3 alien are
On Sat, Sep 8, 2012 at 3:43 AM, Irina Tirdea irina.tir...@gmail.com wrote:
From: Irina Tirdea irina.tir...@intel.com
__WORDSIZE is GLibC-specific and is not defined on all systems or glibc
versions (e.g. Android's bionic does not define it).
In file included from
On Sat, Sep 8, 2012 at 3:43 AM, Irina Tirdea irina.tir...@gmail.com wrote:
From: Irina Tirdea irina.tir...@intel.com
perf uses the glibc version of basename(), by defining _GNU_SOURCE, including
string.h and not including libgen.h. The glibc version of basename is better
than the POSIX
Hi Irina,
I commented on some of the patches but overall, I think the series makes sense:
Acked-by: Pekka Enberg penb...@kernel.org
Pekka
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
.
To all three patches:
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 at http
On Tue, 11 Sep 2012, Christoph Lameter wrote:
On Tue, 11 Sep 2012, Stephen Rothwell wrote:
After merging the final tree, today's linux-next build (sparc64 defconfig)
produced this warning:
mm/slab.c:808:13: warning: '__slab_error' defined but not used
[-Wunused-function]
On Tue, 18 Sep 2012, Dave Jones wrote:
It doesn't seem worth adding a new taint flag for this, so just re-use
the one from 'bad page'
Signed-off-by: Dave Jones da...@redhat.com
On Tue, Sep 18, 2012 at 11:19 PM, David Rientjes rient...@google.com wrote:
Acked-by: David Rientjes
Hi Irina,
On Fri, Sep 21, 2012 at 1:13 AM, Irina Tirdea irina.tir...@gmail.com wrote:
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index b442ee4..c5b4632 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -59,7 +59,8 @@ struct map *map__new(struct list_head
On Tue, Sep 18, 2012 at 5:12 PM, Glauber Costa glom...@parallels.com wrote:
diff --git a/mm/slab.c b/mm/slab.c
index e2cf984..f2d760c 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -4141,8 +4141,19 @@ static int do_tune_cpucache(struct kmem_cache *cachep,
int limit,
static int
On Wed, Sep 19, 2012 at 10:42 AM, Glauber Costa glom...@parallels.com wrote:
index f2d760c..18de3f6 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3938,9 +3938,12 @@ EXPORT_SYMBOL(__kmalloc);
* Free an object which was previously allocated from this
* cache.
*/
-void
Hi Glauber,
On Tue, Sep 18, 2012 at 5:11 PM, Glauber Costa glom...@parallels.com wrote:
This is a followup to the previous kmem series. I divided them logically
so it gets easier for reviewers. But I believe they are ready to be merged
together (although we can do a two-pass merge if people
On Fri, 21 Sep 2012, Glauber Costa wrote:
We should assume that most distributions enable CONFIG_MEMCG_KMEM,
right? Therfore, any performance impact should be dependent on whether
or not kmem memcg is *enabled* at runtime or not.
Can we use the static key thingy introduced by tracing
On Fri, Sep 21, 2012 at 11:07 PM, Tejun Heo t...@kernel.org wrote:
Not necessarily disagreeing, but I don't think it's helpful to set the
bar impossibly high. Even static_key doesn't have exactly *zero*
impact. Let's stick to as minimal as possible when not in use and
reasonable in use.
For
Hi Linus,
Please pull the latest SLAB tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git slab/urgent
It has a PFMALLOC reserve page fixlet for slab from David Rientjes.
Pekka
--
The following changes since commit
On Tue, Sep 11, 2012 at 5:50 AM, Michael Wang
wang...@linux.vnet.ibm.com wrote:
On 09/08/2012 04:39 PM, Pekka Enberg wrote:
On Fri, Sep 7, 2012 at 1:29 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
On Thu, Sep 06, 2012 at 11:05:11AM +0800, Michael Wang wrote:
On 09/05/2012 09:55 PM
On Sat, Jul 14, 2012 at 2:12 AM, Shuah Khan shuah.k...@hp.com wrote:
The label oops is used in CONFIG_DEBUG_VM ifdef block and is defined
outside ifdef CONFIG_DEBUG_VM block. This results in the following
build warning when built with CONFIG_DEBUG_VM disabled. Fix to move
label oops definition
disabled place
slub: refactoring unfreeze_partials()
Julia Lawall (1):
slub: remove invalid reference to list iterator variable
Pekka Enberg (1):
Merge branch 'slub/cleanups' into slab/next
Shuah Khan (1):
mm: Fix build warning in kmem_cache_create()
Thierry Reding (1
On Mon, Jul 30, 2012 at 10:56 PM, David Rientjes rient...@google.com wrote:
-Wunused-label is overridden in gcc for a label that is conditionally
referenced by using __maybe_unused in the kernel. I'm not sure what's so
obscure about
out: __maybe_unused
Are label attributes really that
On Mon, 30 Jul 2012, David Rientjes wrote:
So much for compromise, I thought we had agreed that at least some of the
checks for !name, in_interrupt() or bad size values should be moved out
from under the #ifdef CONFIG_DEBUG_VM, but this wasn't done. This
discussion would be irrelevent if
This patch adds a comment on top of the schedule() function to explain
to scheduler newbies how the main scheduler function is entered.
Explained-by: Ingo Molnar mi...@kernel.org
Explained-by: Peter Zijlstra a.p.zijls...@chello.nl
Signed-off-by: Pekka Enberg penb...@kernel.org
---
kernel/sched
On Wed, 18 Jul 2012, Michael Ellerman wrote:
It occurred to me overnight that I forgot to mention that in order to
build the new code you need the headers from a 3.5-rc1 era kernel (for
the ioctl KVM_CAP definitions).
The easiest way to do that is to merge linus' tree into kvmtool.
Are
On Wed, Aug 29, 2012 at 2:41 PM, Haggai Eran hagg...@mellanox.com wrote:
Looks like a problem in 072bb0aa5e0 (mm: sl[au]b: add knowledge of
PFMEMALLOC reserve pages). cache_grow() can reenable irqs which allows
this to be scheduled on a different cpu, possibly with a different node.
So it
)
return -ENODEV;
+ if (cpu_has_hypervisor)
+ return -ENODEV;
+
ret = uncore_pci_init();
if (ret)
goto fail;
On Tue, Aug 21, 2012 at 3:55 PM, Pekka Enberg penb...@kernel.org wrote:
Tested-by: Pekka Enberg penb...@kernel.org
Ping
On Mon, Sep 3, 2012 at 4:45 AM, Namhyung Kim namhy...@kernel.org wrote:
On Mon, 3 Sep 2012 03:04:32 +0300, Irina Tirdea wrote:
From: Irina Tirdea irina.tir...@intel.com
When NDEBUG is defined, the assert macro will be expanded to nothing.
Some assert calls used in perf are also including some
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
detect if need to use 1G or 2M and store them in page_size_mask.
Only probe them one time.
Suggested-by: Ingo Molnar mi...@elte.hu
Signed-off-by: Yinghai Lu ying...@kernel.org
Reviewed-by: Pekka Enberg penb...@kernel.org
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
from init_memory_mapping, so make init_memory_mapping readable.
Suggested-by: Ingo Molnar mi...@elte.hu
Signed-off-by: Yinghai Lu ying...@kernel.org
Reviewed-by: Pekka Enberg penb...@kernel.org
--
To unsubscribe from
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
from setup.c to mm/init.c
So could update all related calling together later
Signed-off-by: Yinghai Lu ying...@kernel.org
Reviewed-by: Pekka Enberg penb...@kernel.org
--
To unsubscribe from this list: send the line
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
So we could put page table high again for 64bit.
Signed-off-by: Yinghai Lu ying...@kernel.org
The changelog for this is too terse for me to actually understand why
this is needed.
---
arch/x86/mm/init.c |2 +-
1
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
Should not do that in every calling of init_memory_mapping.
Actually in early time, only need do once.
Also move down early_memtest.
Signed-off-by: Yinghai Lu ying...@kernel.org
The changelog is too terse for my liking. I
...@kernel.org
Reviewed-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 at http://www.tux.org/lkml/
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
So later could make it call split_mem_range...
Signed-off-by: Yinghai Lu ying...@kernel.org
The commit title is utterly confusing. And it has a trailing dot (.).
As for the actual change:
Reviewed-by: Pekka Enberg penb
://lkml.org/lkml/2012/8/14/86
Handle it by complaining, and adding the range back into the e820.
Signed-off-by: Jacob Shin jacob.s...@amd.com
This should have Yinghai's sign-off and the warning could be less cryptic.
As for the fix itself:
Reviewed-by: Pekka Enberg penb...@kernel.org
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
From: Jacob Shin jacob.s...@amd.com
Update code that previously assumed pfns [ 0 - max_low_pfn_mapped ) and
[ 4GB - max_pfn_mapped ) were always direct mapped, to now look up
pfn_mapped ranges instead.
What problem does
. - Yinghai Lu
-v3: add calculate_all_table_space_size() to get correct needed page table
size. - Yinghai Lu
Signed-off-by: Jacob Shin jacob.s...@amd.com
Yinghai's sign-off is missing.
Reviewed-by: Pekka Enberg penb...@kernel.org
--
To unsubscribe from this list: send the line unsubscribe
-Yinghai Lu
Signed-off-by: Jacob Shin jacob.s...@amd.com
Yinghai's sign-off is missing.
Reviewed-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
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
+static void __init with_all_ram_ranges(
+ void (*work_fn)(unsigned long, unsigned long, void *),
+ void *data)
+static void __init size_work_fn(unsigned long start, unsigned long
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
This one intend to fix bugs:
when efi booting have too many memmap entries, will need to double memblock
memory array or reserved array.
Okay, why do we need to do that?
+RESERVE_BRK(early_pgt_alloc, 65536);
What is this
On Mon, Sep 3, 2012 at 9:17 AM, Yinghai Lu ying...@kernel.org wrote:
On Sun, Sep 2, 2012 at 10:50 PM, Pekka Enberg penb...@kernel.org wrote:
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
This one intend to fix bugs:
when efi booting have too many memmap entries
On Wed, Sep 5, 2012 at 8:46 AM, Yinghai Lu ying...@kernel.org wrote:
so could reduce one loop.
Signed-off-by: Yinghai Lu ying...@kernel.org
How significant is the speed gain? The isa_done flag makes code flow
more difficult to follow.
---
arch/x86/mm/init.c | 21 ++---
1
On Wed, Sep 5, 2012 at 8:46 AM, Yinghai Lu ying...@kernel.org wrote:
They all need to go over ram range in same sequence. So add shared function
to reduce duplicated code.
-v2: Change to walk_ram_ranges() according to Pekka Enberg.
Signed-off-by: Yinghai Lu ying...@kernel.org
Reviewed
On Mon, 6 Aug 2012, Namhyung Kim wrote:
Now we can support color using pango markup with this change.
Cc: Pekka Enberg penb...@kernel.org
Signed-off-by: Namhyung Kim namhy...@kernel.org
Awesome!
Acked-by: Pekka Enberg penb...@kernel.org
--
To unsubscribe from this list: send the line
On Thu, Aug 16, 2012 at 2:53 AM, Andrew Morton
a...@linux-foundation.org wrote:
On Sun, 12 Aug 2012 10:40:18 -0600
Shuah Khan shuah.k...@hp.com wrote:
kmem_cache_create() does cache integrity checks when CONFIG_DEBUG_VM
is defined. These checks interspersed with the regular code path has
On Sat, 23 Jun 2012, Joonsoo Kim wrote:
In current implementation, after unfreezing, we doesn't touch oldpage,
so it remain 'NOT NULL'. When we call this_cpu_cmpxchg()
with this old oldpage, this_cpu_cmpxchg() is mostly be failed.
We can change value of oldpage to NULL after unfreezing,
Dear wbrana,
On Thu, Aug 23, 2012 at 9:17 PM, wbrana wbr...@gmail.com wrote:
I'm user space developer. User space software also needs more time if
more ABIs are supported.
I feel your pain.
As much as I appreciate your contribution here on LKML, I can't help
thinking that this discussion
Hi Bernard,
(You didn't CC perf maintainers.)
On Thu, Aug 23, 2012 at 6:01 PM, Bernhard Rosenkraenzer
bernhard.rosenkran...@linaro.org wrote:
commit 4dc79eed16e3bb03b3cf92fcc6127e107e7537aa
Author: Bernhard Rosenkraenzer bernhard.rosenkran...@linaro.org
Date: Sat Jun 23 06:18:05 2012 +0200
Dearest wbrana,
On Sat, Aug 25, 2012 at 8:27 PM, wbrana wbr...@gmail.com wrote:
Why did you send this irrelevant e-mail?
So despite my humble suggestion, you've filled up my inbox with
pointless rambling. Would it be at all possible you just got the f*ck
off LKML? I know it's difficult to hear
On Tue, Jul 31, 2012 at 11:18 PM, Dan Magenheimer
dan.magenhei...@oracle.com wrote:
diffstat vs 3.5:
drivers/staging/ramster/Kconfig |2
drivers/staging/ramster/Makefile |2
drivers/staging/zcache/Kconfig|2
drivers/staging/zcache/Makefile |2
This patch adds a comment on top of the schedule() function to explain
to scheduler newbies how the main scheduler function is entered.
Cc: Randy Dunlap rdun...@xenotime.net
Explained-by: Ingo Molnar mi...@kernel.org
Explained-by: Peter Zijlstra a.p.zijls...@chello.nl
Signed-off-by: Pekka Enberg
Hi Konrad,
On Tue, Jul 31, 2012 at 11:53:57PM +0300, Pekka Enberg wrote:
Why on earth would you want to move that under the mm directory?
On Wed, Aug 1, 2012 at 12:04 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
If you take aside that problem that it is one big patch instead
Hi Dan,
On Wed, Aug 1, 2012 at 12:13 AM, Dan Magenheimer
dan.magenhei...@oracle.com wrote:
Ramster does the same thing but manages it peer-to-peer across
multiple systems using kernel sockets. One could argue that
the dependency on sockets makes it more of a driver than mm
but ramster is
On Mon, Aug 6, 2012 at 5:07 PM, Dan Magenheimer
dan.magenhei...@oracle.com wrote:
I'm OK with placing it wherever kernel developers want to put
it, as long as the reason is not NIMBY-ness. [1] My preference
is to keep all the parts together, at least for the review phase,
but if there is a
On Mon, Aug 6, 2012 at 6:24 PM, Dan Magenheimer
dan.magenhei...@oracle.com wrote:
IMHO, the fastest way to get the best zcache into the kernel and
to distros and users is to throw away the demo version, move forward
to a new solid well-designed zcache code base, and work together to
build on
On Mon, Aug 6, 2012 at 7:10 PM, Dan Magenheimer
dan.magenhei...@oracle.com wrote:
Hmmm.. there's also zbud.c and tmem.c which are critical components
of both zcache and ramster. And there are header files as well which
will need to either be in mm/ or somewhere in include/linux/
Is there a
Hello,
I'm seeing this when I dock a Thinkpad X220 laptop:
[ 3129.616279] thinkpad_acpi: unknown possible thermal alarm or
keyboard event received
[ 3129.616297] thinkpad_acpi: unhandled HKEY event 0x6040
[ 3129.616298] thinkpad_acpi: please report the conditions when this
event happened to
On Thu, 16 Aug 2012, Namhyung Kim wrote:
Add helpline API implementation to GTK front-end.
For all three:
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
: assertion `main_loops !=
NULL' failed
Fix it by not to call it unnecessarily.
Reported-by: Pekka Enberg penb...@kernel.org
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/ui/gtk/setup.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/ui/gtk/setup.c b/tools
On Sun, Aug 19, 2012 at 6:46 PM, David Ahern dsah...@gmail.com wrote:
If GTK2 development packages are not installed, make is rather noisy:
[snip]
Signed-off-by: David Ahern dsah...@gmail.com
Cc: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Cc: Pekka Enberg penb...@kernel.org
Cc
On Mon, Aug 20, 2012 at 4:59 AM, Namhyung Kim namhy...@kernel.org wrote:
Forgot to add the #ifdefery to the below code also. :-/ Anyway, it needs
to expose gtk specifics to general code with the #ifdef's. So I'd still
prefer the original patch.
Fair enough.
Acked-by: Pekka Enberg penb
)
return -ENODEV;
+ if (cpu_has_hypervisor)
+ return -ENODEV;
+
ret = uncore_pci_init();
if (ret)
goto fail;
Tested-by: Pekka Enberg penb...@kernel.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Tue, Aug 21, 2012 at 05:08:37PM +0800, Yan, Zheng wrote:
From: Yan, Zheng zheng.z@intel.com
Initializing uncore PMU on virtualized CPU may hang the kernel.
This is because kvm does not emulate the entire hardware. Thers
are lots of uncore related MSRs, making kvm enumerate them all
is
Hi Nick,
On Feb 3, 2008 11:52 AM, Nick Piggin [EMAIL PROTECTED] wrote:
+asmlinkage void smp_call_function_fast_interrupt(void)
+{
[snip]
+ while (!list_empty(list)) {
+ struct call_single_data *data;
+
+ data = list_entry(list.next, struct
Hi Christer,
On Feb 3, 2008 1:48 PM, Christer Weinigel [EMAIL PROTECTED] wrote:
Saying use BSD instead isn't a good answer for me since I don't know
BSD well enough. And personally, I want to see Linux everywhere; I
think it's a lot better to have Linux + a proprietary driver in an
embedded
Hi David,
On Feb 3, 2008 5:12 PM, David Newall [EMAIL PROTECTED] wrote:
By the way, I'm almost certain that the COPYING file is the first, last
and only document specifying licence conditions, and nothing in that
prevents a proprietary driver from including a patch that, for example,
globally
Hi David,
On Feb 3, 2008 6:06 PM, David Newall [EMAIL PROTECTED] wrote:
But what I don't understand is why people insist using the Linux kernel
for something it clearly can never really properly support (proprietary
code)?
That's defeatist. Of course the Linux kernel can properly support
Hi David,
Marcel Holtmann writes:
You driver was meant to be running as Linux kernel module and thus it is
derivative work.
On Feb 5, 2008 1:39 PM, David Newall [EMAIL PROTECTED] wrote:
It is precisely the fact that it is a loadable module, and does not form
part of the kernel, that
Christoph Lameter wrote:
On Tue, 5 Feb 2008, Pekka J Enberg wrote:
Hi Christoph,
On Mon, 4 Feb 2008, Christoph Lameter wrote:
The statistics provided here allow the monitoring of allocator behavior
at the cost of some (minimal) loss of performance. Counters are placed in
SLUB's per cpu data
Hi,
On Feb 6, 2008 10:21 PM, [EMAIL PROTECTED] wrote:
From reboot after last hang on 02/03/08, I found this...
Feb 5 23:26:26 sc-software kernel: [ cut here ]
Feb 5 23:26:26 sc-software kernel: kernel BUG at mm/slab.c:591!
Feb 5 23:26:26 sc-software kernel:
Hi David,
On Feb 7, 2008 3:31 PM, David Newall [EMAIL PROTECTED] wrote:
This *is* real work. You have blinded yourself to the fact that this
discussion is preliminary to a proposed change.
Or put another way, if you want to kill the discussion then the answer
to shall we is no.
Ok. I am
Hi Christoph,
Christoph Lameter wrote:
SLABs can be excepted from tracking?
Yes. __GFP_NOTRACK can be used to suppress tracking of objects (but we
still take the page fault for each access). That is required for things
like DMA filled pages that are never initialized by the CPU.
Pekka Enberg wrote:
No. We need to not track the whole page to avoid recursive faults. So
for kmemcheck we absolutely do need cache_cache but we can, of course,
hide that under a alloc_cache() function that only uses the extra cache
when CONFIG_KMEMCHECK is enabled?
Btw, one option
On Feb 8, 2008 1:32 AM, Christoph Lameter [EMAIL PROTECTED] wrote:
But the slab layer allocates pages PAGE_SIZE. You need to take a fault
right? So each object would need its own page?
No. We allocate a shadow page for each data page which we then use as
a per-byte bitmap. For every tracked
On Feb 8, 2008 2:15 PM, Andi Kleen [EMAIL PROTECTED] wrote:
need to worry about it just yet. In case it's from kmalloc() you can
pass __GFP_NOTRACK to annotate those call sites where the memory is
Ok you should add that then to skbuff.c.
Indeed. If you look at the second patch, I think Ingo
Hi Andi,
On Feb 8, 2008 1:55 PM, Andi Kleen [EMAIL PROTECTED] wrote:
Also i'm not sure how you handle initializedness of DMAed data
(like network buffers). Wouldn't you need hooks into pci_dma_*
for this?
If the DMA'd memory is allocated from the page allocator, we don't
need to worry about
401 - 500 of 1778 matches
Mail list logo
