Hi Andi,
On Feb 8, 2008 1:55 PM, Andi Kleen [EMAIL PROTECTED] wrote:
Impressive patch! On the other hand a lot of the interesting
data isn't it kmalloc anymore, but in slab. Does it really track
all that much?
It tracks all slab caches. What we're not tracking is pages from the
page allocator
Hi Andi,
On Feb 8, 2008 2:10 PM, Andi Kleen [EMAIL PROTECTED] wrote:
It's probably tricky; there are all kinds of hidden page faults
on x86 on data structures allocated as pages (e.g. GDT, LDT [which
is sometimes kmalloc too], stack etc.)
Aah, I see. We can annotate those callers to disable
Hi,
On Jan 29, 2008 1:33 AM, Randy Dunlap [EMAIL PROTECTED] wrote:
What part of kernel documentation uses doxygen?
So then, what's the problem?
Why is it there? We have a kernel documentation language.
Please use it or plain text.
Yes please.
Pekka
--
To
Hi,
On Jan 30, 2008 8:41 AM, CooperYuan Cooper [EMAIL PROTECTED] wrote:
Now I am porting a device driver to Linux, its source code is not opened.
In this module, I use some interface functions exported from GPL
module through EXPORT_SYMBOL macros. (not EXPORT_SYMBOL_GPL), For
example,
Hi,
On Feb 2, 2008 8:25 PM, Ondrej Zary [EMAIL PROTECTED] wrote:
+//static __be16 el3_phys_addr[EL3_MAX_CARDS][3];
[snip]
+//#if defined(CONFIG_MCA) || defined(CONFIG_EISA)
[snip]
+// while (el3_probe(el3_cards) == 0) {
+// if (irq[el3_cards] 1)
+//
Hi,
On Jan 17, 2008 8:34 AM, CaT [EMAIL PROTECTED] wrote:
There are 75 processes on the box of which almost 47 are kernel
processes + init. Of the rest, the top 3 have an RSS of 9.4meg, 6.2meg
and 4.8meg, 7 are at around 2meg and the rest are below 2meg with the
majority below 1. So unless
Hi Olaf,
[Adding Christoph as cc.]
On Jan 15, 2008 5:09 PM, Olaf Hering [EMAIL PROTECTED] wrote:
Current linus tree crashes in kmem_cache_init, as shown below. The
system is a 8cpu 2.2GHz POWER5 system, model 9117-570, with 4GB ram.
Firmware is 240_332, 2.6.23 boots ok with the same config.
Hi Thomas,
On Jan 19, 2008 10:00 PM, Thomas Renninger [EMAIL PROTECTED] wrote:
+static int pnp_alloc_port(struct pnp_resource_table *res)
+{
[snip]
+ res-port_resource = krealloc(res-port_resource,
+ (sizeof(struct resource) * res-allocated_ports)
+ +
Hi,
Mel Gorman wrote:
Faulting instruction address: 0xc03c8c00
cpu 0x0: Vector: 300 (Data Access) at [c05c3840]
pc: c03c8c00: __lock_text_start+0x20/0x88
lr: c00dadec: .cache_grow+0x7c/0x338
sp: c05c3ac0
msr: 80009032
dar: 40
Hi Christoph,
On Jan 23, 2008 1:18 AM, Christoph Lameter [EMAIL PROTECTED] wrote:
My patch is useless (fascinating history of the changelog there through).
fallback_alloc calls kmem_getpages without GFP_THISNODE. This means that
alloc_pages_node() will try to allocate on the current node but
Hi,
On Jan 23, 2008 9:52 PM, Nishanth Aravamudan [EMAIL PROTECTED] wrote:
On at least one of the machines in question, wasn't it the case that
node 0 had all the memory and node 1 had all the CPUs? In that case, you
would have to boot off a memoryless node? And as long as that is a
physically
Hi Wilco,
On Jan 24, 2008 12:05 PM, Wilco Beekhuizen [EMAIL PROTECTED] wrote:
Most code is pretty ancient, I just manage it so it compiles with
recent kernels. Is there somehting exported that is similar to
usb_find_device?
The problem is that iriverfs shouldn't be calling usb_find_device()
Hi Oliver,
On Jan 24, 2008 1:49 PM, Oliver Neukum [EMAIL PROTECTED] wrote:
A quick glance through the files at sourceforge indicates that this
device use a file transfer protocol. Mapping this to a simple device
is hard. A fs is quite natural a representation of that.
Sure but the filesystems
Hi Oliver,
On Jan 24, 2008 2:24 PM, Oliver Neukum [EMAIL PROTECTED] wrote:
Sure but the filesystems in fs/ are general purpose and they can be
mounted on top of any block device (except for the in-memory ones like
nfs, cifs, jffs, ...
But none of them mess around with *hardware*. Sure, you
Hi,
On Jan 24, 2008 2:58 PM, Oliver Neukum [EMAIL PROTECTED] wrote:
So we put it into drivers/usb/misc
Does that change the code?
Yes. It's assumes only one device is plugged in.
On Jan 24, 2008 2:58 PM, Oliver Neukum [EMAIL PROTECTED] wrote:
How do you make a block device on top of this
Hi Greg,
On Jan 24, 2008 6:44 PM, Greg KH [EMAIL PROTECTED] wrote:
No, that's not the problem. The code should just be using
usb_register_driver() and then doing what it needs to do in the probe()
callback, like any other USB driver.
By calling usb_find_device() it allows more than one
Hi Greg,
On Jan 24, 2008 7:20 PM, Greg KH [EMAIL PROTECTED] wrote:
So it's not a simple code change at all.
Just create a root directory for every device that is seen in the
probe() function. That should be pretty simple to do.
Yeah, that would work but why do we want to mount all devices
Hi Oliver,
On Jan 24, 2008 9:57 PM, Oliver Neukum [EMAIL PROTECTED] wrote:
Are you proposing to mount a _character_ device?
/me looks
Yeah, I am proposing to mount whatever usb_register_dev() pops up in
/dev (which indeed is a character device). Is that a problem?
Pekka
Hi,
On Jan 24, 2008 10:00 PM, Oliver Neukum [EMAIL PROTECTED] wrote:
A discussion about lifetime rules for objects in sysfs anyone? ;-
Furthermore, you need to unmount all devices before you can unplug one of them.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Hi,
diff -uprN -X linux-2.6.24-rc8/Documentation/dontdiff
linux-2.6.24-rc8/include/linux/ext3_fs_sb.h
linux-2.6.24-rc8-freeze/include/linux/ext3_fs_sb.h
--- linux-2.6.24-rc8/include/linux/ext3_fs_sb.h 2008-01-16 13:22:48.0
+0900
+++
Hi Thomas,
On Sun, 2008-01-20 at 02:23 +0200, Pekka Enberg wrote:
When krealloc() returns NULL, there wasn't enough memory to fit the
new size but the original memory region remains unchanged.
On Jan 23, 2008 7:38 PM, Thomas Renninger [EMAIL PROTECTED] wrote:
Thanks Pekka, this one should
Hi Vegard,
On Jan 27, 2008 10:07 PM, Vegard Nossum [EMAIL PROTECTED] wrote:
I am testing my kmemcheck patches, and it has come up with a couple of
uses of uninitialized memory in lib/idr.c. These are (the line numbers
may differ slightly):
[snip]
@@ -39,12 +39,16 @@ static struct idr_layer
Hi Vegard,
On Jan 27, 2008 11:30 PM, Vegard Nossum [EMAIL PROTECTED] wrote:
Depends on how you track object initialization. An object returned by
kmem_cache_alloc() is always initialized if the cache it comes from has a
constructor.
I think there's a pretty big chance I'm wrong (or
Hi,
On Feb 16, 2008 12:18 PM, Thomas Gleixner [EMAIL PROTECTED] wrote:
People, who do cleanups - I'm not talking about running lindent here -
read through the code while they fix it up.
Actually they find bugs that way or at least come up with useful
questions about code which is not obvious
Hi Yanmin,
On Fri, 2008-02-15 at 08:42 -0800, Christoph Lameter wrote:
Kernel panic at line 1637 in file mm/slub.c because
object=c-freelist=NULL.
H. freelist should never be NULL. Could you rerun the test and boot with
slub_debug to make sure that there is no memory corruption?
Hi,
Pekka Enberg [EMAIL PROTECTED] wrote:
Mathieu, Christoph is on vacation and I'm not at all that familiar
with this cmpxchg_local() optimization, so if you could take a peek at
this bug report to see if you can spot something obviously wrong with
it, I would much appreciate
Hi Mathieu,
On Feb 19, 2008 4:02 PM, Mathieu Desnoyers [EMAIL PROTECTED] wrote:
Since this shows mostly with network card drivers, I think the most
plausible cause would be an IRQ nesting over kmem_cache_alloc_node and
calling it.
On Feb 19, 2008 4:21 PM, Pekka Enberg [EMAIL PROTECTED
Hi Mathieu,
On Feb 19, 2008 4:02 PM, Mathieu Desnoyers [EMAIL PROTECTED] wrote:
- stat(c, ALLOC_FASTPATH); seems to be using a var++, therefore
indicating it is not reentrant if IRQs are disabled. Since those are
only stats, I guess it's ok, but still weird.
What is not re-entrant?
On
Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
If this (or my other patch) indeed solves the problem i'd still favor
a full revert of the SLUB_FASTPATH (commit 1f84260c8ce3b1ce26d4), it
looks quite un-cooked and quite un-tested for multiple independent
reasons.
Sigh, why do i
Ingo Molnar wrote:
* Pekka Enberg [EMAIL PROTECTED] wrote:
Yes, this can happen. Are you saying it is not safe to be in the
lockless path when an IRQ triggers?
Hmm. The barrier() in slab_free() looks fishy. The comment says it's
there to make sure we've retrieved c-freelist before c-page
On 2/20/2008, Zhang, Yanmin [EMAIL PROTECTED] wrote:
Kernel with the reverting patch is ok.
I ran reboot/hackbench for more than 10 times on every one of my 3 x86-64
machines, and kernel didn't crash.
Great, Linus reverted the patch yesterday. Thanks for testing!
--
To unsubscribe from this
Hi Adrian,
On 2/20/2008, Adrian Bunk [EMAIL PROTECTED] wrote:
The Coverity checker spotted the following inconsequent NULL checking
introduced by commit 8ff12cfc009a2a38d87fa7058226fe197bb2696f:
-- snip --
...
static inline int is_end(void *addr)
{
return (unsigned long)addr
);
/*
* Merge cpu freelist into freelist. Typically we get here
* because both freelists are empty. So this is unlikely
Christoph, please apply.
Reviewed-by: Pekka Enberg [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On Sat, Feb 23, 2008 at 1:07 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
I have to say, after having observed multiple incidents around b43 in
the past few months you are one of the worst driver maintainers i've
ever seen on lkml: you are ignoring regressions, you are frequently
insulting our
On Sat, Feb 23, 2008 at 1:32 PM, Alexey Zaytsev
[EMAIL PROTECTED] wrote:
The problem is not with enabling both b43 and bcm43xx (will, whis won't work
anyway, and there is no chance fixing it). The problem is with enabling the
bcm43xx wifi driver and the b44 Ethernet driver. The ethernet
On Sat, Feb 23, 2008 at 10:11 AM, Andrew Morton
[EMAIL PROTECTED] wrote:
Seems a poor idea to me. Sure, oprofile is hard to set up, but not if
your distributor already did it for you.
Have you tried sysprof? It's really nice to setup and use compared to
oprofile when profiling user-space.
Hi,
On Sat, Feb 23, 2008 at 2:37 PM, Pekka Enberg [EMAIL PROTECTED] wrote:
So does reverting commit 753f492093da7a40141bfe083073400f518f4c68
([B44]: port to native ssb support) fix the regression?
On Sat, Feb 23, 2008 at 2:17 PM, Alexey Zaytsev
[EMAIL PROTECTED] wrote:
Yes
Hi Ingo,
On Sat, Feb 23, 2008 at 2:22 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
As a comparison, here's a session of a newbie developer, meeting
oprofile for the first time in his life (using a fresh package,
oprofile-0.9.3-6.fc8):
--
[ Newbie: WTF, no GUI tool? ]
On Sat, Feb 23, 2008 at 10:11 AM, Andrew Morton
[EMAIL PROTECTED] wrote:
Seems a poor idea to me. Sure, oprofile is hard to set up, but not if
your distributor already did it for you.
Sidebar: the code uses the utterly crappy register_timer_hook() which
a) is woefully misnamed and
b)
Hi Andrew,
Andrew Morton wrote:
I didn't need to write a new kernel module to enable that
thirteen-character shell script, and I don't believe one needs to write a
new kernel module to put a nice easy-to-use GUI around oprofile either.
This is one of those
On Mon, Feb 25, 2008 at 11:54 AM, Michael Buesch [EMAIL PROTECTED] wrote:
Isn't the resolution Michael is suggesting is, use the different driver?
I have two resolutions. One being:
rmmod b44
rmmod ssb
modprobe bcm43xx
modprobe b44
The other being: Wait for 2.6.25 and use the
Hi Stephane,
On Mon, Feb 25, 2008 at 7:00 PM, stephane eranian
[EMAIL PROTECTED] wrote:
I have finally released the perfmon2 kernel patch for kernel v2.6.24. It
took longer than expected to due my job change and several technical issues
related to perfmon kernel bugs.
[snip]
As usual
On Sun, Feb 24, 2008 at 5:12 AM, Nicholas Miell [EMAIL PROTECTED] wrote:
Sysprof tracks the full stack frame so it can provide meaningful call
tree (who called what) which is invaluable for spotting hot _paths_. I
don't see how oprofile can do that as it tracks instruction pointers only.
Hi,
On Tue, Feb 26, 2008 at 8:27 AM, Pekka Enberg [EMAIL PROTECTED] wrote:
You could try passing the --callgraph option to opcontrol.
Hmm, perhaps I am missing something but I don't think that does what
sysprof does. At least I can't find where in the oprofile kernel code
does it save
On Tue, Feb 26, 2008 at 12:24 PM, [EMAIL PROTECTED] wrote:
Maybe I found a type miss in fs/ext2/ext2.h which is in linux-2.6.24.3, and
write difference below.
You probably want to read Documentation/SubmittingPatches first and
re-send the patch in the proper format.
On 2/2/07, Jan Dittmer [EMAIL PROTECTED] wrote:
Pekka, it would be better if you could sort out most of the
basic issues with lirc directly with the developers of lirc
and then prepare a complete patch series and post that to
lkml. Incrementally adding one driver after another. Posting
patches
Hi Joerg,
On 2/5/07, Joerg Roedel [EMAIL PROTECTED] wrote:
Hmm, this seems to be the same issue as in [1] and [2]. A page that is
assumed to belong to the slab but is not longer marked as a slab page.
Could this be a bug in the memory management?
The BUG_ON triggers whenever you feed an
Hi,
On Thu, Feb 08, 2007 at 07:46:47PM +0100, Miklos Szeredi wrote:
It boots fine, then usually just after logging in and before starting
the shell (but sometimes after the shell started) it gets into some
loop. Looking at the strace shows that two processes are
sending/receiving single
Hi Michael,
On Sat, 2007-11-03 at 21:06 +0100, Michael Buesch wrote:
Who is responsible for slab btw?
I mean, someone should be interested in getting this bug fixed. :)
When using slab I see random corruptions. I think related to rmmod, but
I'm not sure. I don't see this with slub.
Is
Hi Michael,
On Monday 05 November 2007 13:23:50 Pekka Enberg wrote:
Is CONFIG_DEBUG_SLAB enabled? Usually these kind of random corruptions
are caused by someone passing a bad pointer to kfree() or
kmem_cache_free().
On 11/5/07, Michael Buesch [EMAIL PROTECTED] wrote:
Yeah.
What I also
On Sun, 8 Jul 2012, Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be
On Sun, 8 Jul 2012, David Rientjes wrote:
The correct fix is what I proposed at
http://marc.info/?l=linux-kernelm=133754837703630 and was awaiting
testing. If Rus, Steven, or Fengguang could test this then we could add
it as a stable backport as well.
Looks good to me. Care to send it my
On Mon, 9 Jul 2012, David Rientjes wrote:
kmemcheck_alloc_shadow() requires irqs to be enabled, so wait to disable
them until after its called for __GFP_WAIT allocations.
This fixes a warning for such allocations:
WARNING: at kernel/lockdep.c:2739 lockdep_trace_alloc+0x14e/0x1c0()
On Jul 10, 2012, at 6:17, w...@linux.intel.com wrote:
This commit crashes the kernel w/o any dmesg output (the attached one
is created by the script as a summary for that run). This is very
reproducible in kvm for the attached config.
commit 3b0efdfa1e719303536c04d9abca43abeb40f80a
On Tue, 10 Jul 2012, Christoph Lameter wrote:
Here is the patch:
Subject: slob: Undo slob hunk
Commit fd3142a59af2012a7c5dc72ec97a4935ff1c5fc6 broke
slob since a piece of a change for a later patch slipped into
it.
Signed-off-by: Christoph Lameter c...@linux.com
---
mm/slob.c |
On Thu, Jul 19, 2012 at 6:42 PM, Namhyung Kim namhy...@kernel.org wrote:
Now we can support color using pango markup with this change.
Signed-off-by: Namhyung Kim namhy...@kernel.org
Can you please CC me on perf GTK patches?
[snip]
+#define HPP_COLOR_FN(_name, _field)
On Thu, Dec 6, 2012 at 6:09 PM, Joonsoo Kim js1...@gmail.com wrote:
The purpose of iterating a vmlist is finding vm area with specific
virtual address. find_vm_area() is provided for this purpose
and more efficient, because it uses a rbtree.
So change it.
You no longer take the 'vmlist_lock'.
On Mon, Dec 10, 2012 at 11:57 PM, Sasha Levin sasha.le...@oracle.com wrote:
On 12/10/2012 04:50 PM, Michel Lespinasse wrote:
On Mon, Dec 10, 2012 at 8:22 AM, Sasha Levin levinsasha...@gmail.com wrote:
Ping?
Hey Sasha,
There seems to have been some confusion here. After your last message,
I
we reserve them before we are using memblock to find
free mem to use.
Signed-off-by: Yinghai Lu ying...@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
On Wed, 21 Nov 2012, Andrew Morton wrote:
The proposed API bugs me a bit. It seems simplistic. I need to have a
quality think about this. Maybe the result of that think will be to
suggest an interface which can be extended in a back-compatible fashion
later on, if/when the simplistic nature
On Sat, Nov 24, 2012 at 10:29 AM, dyo...@redhat.com wrote:
For old glibc there's no the syscall number this tests will cause
make run_tests fail.
Add a macro to define the number. This should be ok because it will be
built in latest kernel source.
Signed-off-by: Dave Young dyo...@redhat.com
-test.sh: Permission denied
memory-hotplug selftests: [FAIL]
make: Leaving directory
`/home/dave/git/linux-2.6/tools/testing/selftests/memory-hotplug'
Signed-off-by: Dave Young dyo...@redhat.com
Reviewed-by: Pekka Enberg penb...@kernel.org
It'd be good if we could turn off the make produced
: Permission denied
cpu-hotplug selftests: [FAIL]
make: Leaving directory
`/home/dave/git/linux-2.6/tools/testing/selftests/cpu-hotplug'
Signed-off-by: Dave Young dyo...@redhat.com
Reviewed-by: Pekka Enberg penb...@kernel.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
+ @./mq_open_tests /test1 || echo mq_open_tests: [FAIL]
+ @./mq_perf_tests || echo mq_perf_tests: [FAIL]
Reviewed-by: Pekka Enberg penb...@kernel.org
I wonder though if we can make this more generic at higher level.
Maybe use Python or something instead of Makefiles for test case
definition
On Sat, Nov 24, 2012 at 10:29 AM, dyo...@redhat.com wrote:
In case kcmp_test exit non zero value it will cause make error.
Better way is just print the test failure status.
Signed-off-by: Dave Young dyo...@redhat.com
Reviewed-by: Pekka Enberg penb...@kernel.org
---
tools/testing
On Sat, Nov 24, 2012 at 10:29 AM, dyo...@redhat.com wrote:
In case breakpoint test exit non zero value it will cause make error.
Better way is just print the test failure status.
Signed-off-by: Dave Young dyo...@redhat.com
Reviewed-by: Pekka Enberg penb...@kernel.org
---
tools/testing
in cache creation
Joonsoo Kim (1):
slub: remove one code path and reduce lock contention in __slab_free()
Pekka Enberg (3):
Merge branch 'slab/procfs' into slab/next
Merge branch 'slab/procfs' into slab/for-linus
Merge branch 'slab/next' into slab/for-linus
Randy Dunlap (1
On Sun, 23 Dec 2012, Sasha Levin wrote:
diff --git a/mm/bootmem.c b/mm/bootmem.c
index 1324cd7..198a92f 100644
--- a/mm/bootmem.c
+++ b/mm/bootmem.c
@@ -763,9 +763,6 @@ void * __init ___alloc_bootmem_node(pg_data_t *pgdat,
unsigned long size,
void * __init __alloc_bootmem_node(pg_data_t
On Fri, Dec 28, 2012 at 12:31 AM, David Rientjes rient...@google.com wrote:
On Fri, 28 Dec 2012, Pekka Enberg wrote:
On Sun, 23 Dec 2012, Sasha Levin wrote:
diff --git a/mm/bootmem.c b/mm/bootmem.c
index 1324cd7..198a92f 100644
--- a/mm/bootmem.c
+++ b/mm/bootmem.c
@@ -763,9 +763,6
On Thu, 15 Nov 2012, Namhyung Kim wrote:
This is an RFC patchset to separate GTK GUI codes to a shared object,
called libperf-gtk.so and use it with libdl. It's in an early-stage
so probably has some rough edges, but I'd like to get some comments.
For now, the libperf-gtk.so (I'm open to a
On Tue, 13 Nov 2012, Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
Implement progress update function for GTK2 front end.
Note that since it will be called before gtk main loop so that
we should call gtk event loop handler directly.
Cc: Pekka Enberg penb...@kernel.org
Hello,
[ Found this in my @cs.helsinki.fi inbox, grmbl. ]
On Fri, Sep 28, 2012 at 11:39 PM, David Rientjes rient...@google.com wrote:
The first prototype, SLAM XP1, will be posted in October. I'd simply like
to avoid reverting this patch down the road and having all of us
reconsider the
Hi Nick,
On 7/9/07, Nick Piggin [EMAIL PROTECTED] wrote:
SLOB contains several significant O(1) and also O(n) memory savings that
are so far impossible-by-design for SLUB. They are: slab external
fragmentation is significantly reduced; kmalloc internal fragmentation is
significantly reduced;
Hi Nick,
Pekka Enberg wrote:
I assume with slab external fragmentation you mean allocating a
whole page for a slab when there are not enough objects to fill the
whole thing thus wasting memory?
On 7/9/07, Nick Piggin [EMAIL PROTECTED] wrote:
Yep. Without really analysing it, I guess
Hi Nick,
Pekka J Enberg wrote:
That's 92 KB advantage for SLUB with debugging enabled and 240 KB when
debugging is disabled.
On 7/10/07, Nick Piggin [EMAIL PROTECTED] wrote:
Interesting. What kernel version are you using?
Linus' git head from yesterday so the results are likely to be
Hi Andrew,
On 7/10/07, Andrew Morton [EMAIL PROTECTED] wrote:
revoke-special-mmap-handling.patch
revoke-special-mmap-handling-vs-fault-vs-invalidate.patch
revoke-core-code.patch
revoke-support-for-ext2-and-ext3.patch
revoke-add-documentation.patch
revoke-wire-up-i386-system-calls.patch
Hi Al,
On Wed, Jul 11, 2007 at 11:41:35AM +0300, Pekka Enberg wrote:
Well, revoke is in limbo land waiting for the VFS maintainers to take
a look at it...
On 7/11/07, Al Viro [EMAIL PROTECTED] wrote:
Could you send a sanely split series against the .22 to fsdevel?
I sent the series from
Hi Andrew,
On 7/11/07, Pekka Enberg [EMAIL PROTECTED] wrote:
Well, revoke is in limbo land waiting for the VFS maintainers to take
a look at it...
Al took a peek at it and found holes. So no need to worry about merging yet :-)
-
To unsubscribe from this list: send the line unsubscribe linux
On 7/12/07, Martijn Uffing [EMAIL PROTECTED] wrote:
I must miss something really really obvious, but I really can't find it.
[snip]
drivers/i2c/chips/bt869.c:63: error: field `update_lock' has incomplete type
[snip]
@@ -59,7 +60,7 @@ struct bt869_data {
struct i2c_client client;
On 7/13/07, Kalpak Shah [EMAIL PROTECTED] wrote:
EXT4_DIR_LINK_MAX() is buggy: it evaluates its arg twice.
#define EXT4_DIR_LINK_MAX(dir) (!is_dx(dir) (dir)-i_nlink = EXT4_LINK_MAX)
[snip]
Sorry, I didn't understand what is the problem with this macro?
The expression represented by
Hi Kirill,
On 7/13/07, Kirill Korotaev [EMAIL PROTECTED] wrote:
Look, until you have any numbers in hands it's impossible to say
which one is faster.
Well, it's not too hard to guess: struct dentry is 124 bytes on i386
so kmem_cache_zalloc over it is bound to be slower tha
kmem_cache_alloc as
.
Looks good to me.
Acked-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://www.tux.org/lkml/
remaining in SLAB.
Make slub return NULL like the other allocators if a too large
memory segment is requested via __kmalloc.
Looks good to me.
Acked-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
in derived allocators such as in the uncached
allocator and the pool allocators.
[snip]
So add the necessary logic to all slab allocators to support __GFP_ZERO.
Looks good to me.
Acked-by: Pekka Enberg [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On 6/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
+static inline void *kmem_cache_zalloc(struct kmem_cache *k, gfp_t flags)
+{
+ return kmem_cache_alloc(k, flags | __GFP_ZERO);
+}
+
+static inline void *__kzalloc(int size, gfp_t flags)
+{
+ return kmalloc(size, flags |
On 6/18/07, Pekka Enberg [EMAIL PROTECTED] wrote:
Hmm, did you check kernel text size before and after this change?
Setting the __GFP_ZERO flag at every kzalloc call-site seems like a
bad idea.
Aah but most call-sites, of course, use constants such as GFP_KERNEL
only which should be folded
On 6/19/2007, Christoph Lameter [EMAIL PROTECTED] wrote:
IA64
[snip]
Saved ~500 bytes in text size.
x86_64:
[snip]
200 bytes saved.
Looks good. Thanks Christoph.
Acked-by: Pekka Enberg [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
Hi Alexandre,
On 6/19/07, Alexandre Oliva [EMAIL PROTECTED] wrote:
Dispute this:
non-tivoized hardware = users can scratch their itches = more
contributions from these users
tivoized hardware = users can't scratch their itches = fewer
contributions from these users
Maybe, but in what
Hi Alexandre,
At some point in time, I wrote:
Furthermore, Linus has repeatedly explained to you why he (and bunch
of other _kernel_ hackers -- this is a thread on LKML, remember)
thinks it's stupid for a software license to restrict hardware
design choices.
On 6/19/07, Alexandre Oliva
(expect maybe kzalloc which is wide-spread now)?
Acked-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
On 6/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
We use the parameter formerly used by the destructor to pass an optional
pointer to a kmem_cache_ops structure to kmem_cache_create.
kmem_cache_ops is created as empty. Later patches populate kmem_cache_ops.
I like kmem_cache_ops but I
Hi Christoph x 2,
On Tue, 19 Jun 2007, Christoph Hellwig wrote:
Hmm, I must have missed the macro going in. Frankly speaking I plain hate
it. It's a rather useless obsfucation.
I hate the name, but the macro is far from useless.
On 6/19/07, Christoph Lameter [EMAIL PROTECTED] wrote:
It
On 5/31/07, Thomas Renninger [EMAIL PROTECTED] wrote:
(This should efficiently be the same as the proposed big patch a year
ago from Pekka Enberg, just a bit smaller and should make ACPICA and
kernel/linux people happy:
http://marc.info/?l=linux-kernelm=113699535303722w=2)
No, you're keeping
On Fri, 1 Jun 2007, Andrew Morton wrote:
They are different instances which happen to have the same length (zero).
On 6/2/07, Christoph Lameter [EMAIL PROTECTED] wrote:
I guess one could use the slab allocators as a type of reservation
ticket generator with zero sized objects. Hmmm But
On 6/4/07, Christoph Lameter [EMAIL PROTECTED] wrote:
We are doing that right now. The problem is that people keep storing stuff
in memory allocated with kmalloc(0).
Ok, makes sense. I guess I might as well throw my suggestion in the
mix. Lets create a new kmalloc cache for zero-length objects
On 6/4/07, Linus Torvalds [EMAIL PROTECTED] wrote:
Well, the red-zones won't catch readers, and more importantly, even for
writers they are *really* inconvenient, because it will just tell you
something bad happened, it won't tell you *where* it happened.
True.
On 6/4/07, Linus Torvalds
On 6/4/07, Roland Dreier [EMAIL PROTECTED] wrote:
No, because as was mentioned earlier in the thread, we want code to be
able to handle 0-sized allocations without special cases. The goal is
that code like
buf = kmalloc(nobj * obj_size);
if (buf == NULL)
return
Hi Rene,
On 6/4/07, Rene Herman [EMAIL PROTECTED] wrote:
BUG: unable to handle kernel paging request at virtual address 8c1d2071
printing eip:
c10a6d6f
*pde =
Oops: 0002 [#1]
Modules linked in: mitsumi nfsd exportfs lockd sunrpc nls_cp437 msdos
fat nls_base
CPU:0
EIP:
Hi Christoph,
On 6/4/07, Christoph Lameter [EMAIL PROTECTED] wrote:
/*
-* We should return 0 if size == 0 (which would result in the
-* kmalloc caller to get NULL) but we use the smallest object
-* here for legacy reasons. Just issue a warning so that
-*
Christoph Lameter wrote:
That is another patchset. See
http://marc.info/?l=linux-kernelw=2r=1s=DEVELKERNELq=b
Oh my, I am totally confused now.
First you fix kmalloc(0) to be legal and safe. And then you want to
DEVEL_WARN_ON_ONCE when size is zero so people can fix their code?
I don't get
501 - 600 of 1778 matches
Mail list logo
