On Sep 24, 2012, at 3:12, Glauber Costa wrote:
> On 09/21/2012 10:14 PM, Tejun Heo wrote:
>
> The new caches will appear under /proc/slabinfo with the rest, with a
> string appended that identifies the group.
There are f.e. meminfo files in the per node directories in sysfs. It would
make sen
Please pull from pekkas tree on github or use next (check if the back and forth
with patchset in and out has been resolved first).
--
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.
Yes that fix was already sent by me.
On Sep 8, 2012, at 22:42, Hugh Dickins wrote:
> Latest mmotm rarely boots if SLUB is enabled: earlyprintk=vga shows
> it crashing with various backtraces. The memset has now been removed
> from kmem_cache_open(), so kmem_cache_init() needs to zero its page
Acked-by: Christoph Lameter
On Aug 12, 2012, at 11:40, Shuah Khan wrote:
> kmem_cache_create() does cache integrity checks when CONFIG_DEBUG_VM
> is defined. These checks interspersed with the regular code path has
> lead to compile time warnings when compiled without CONFIG
While you are at it: Could you move the code into slab_common.c so that there
is only one version to maintain?
On Sep 27, 2012, at 17:04, KOSAKI Motohiro wrote:
> (9/27/12 2:47 AM), Lai Jiangshan wrote:
>> SLUB only fucus on the nodes which has normal memory, so ignore the other
>> node's hot-a
On Fri, Jun 08, 2007 at 09:59:20AM +0200, Carsten Otte wrote:
> Christoph Hellwig wrote:
> >Jared's patch currently does ioremap on mount (and no iounmap at all).
> >That mapping needs to move from the filesystem to the device driver.
> The device driver needs to do ioremap
On Fri, Jun 08, 2007 at 09:50:17AM +0200, Carsten Otte wrote:
> I see your poing with regard to layering, and I agree to it.
> In order to do ioremap/iounmap at least we need a counterpart
> put_xip_page thing to do iounmap in that path. Our dcss segments on
> 390 did not raise that requirement:
On Fri, Jun 08, 2007 at 09:17:18AM +0200, Carsten Otte wrote:
> Christoph Hellwig wrote:
> >On Thu, Jun 07, 2007 at 07:07:54PM +0200, Carsten Otte wrote:
> >>I've had a few beer long discussion with Joern Engel and David
> >>Woodhouse on this one. To cut a long d
On Thu, Jun 07, 2007 at 01:34:12PM -0700, Jared Hulbert wrote:
> >And we'll need that even when using cramfs. There's not way we'd
> >merge a hack where the user has to specify a physical address on
> >the mount command line.
>
> Why not? For the use case in question the user usually manually
>
On Fri, 8 Jun 2007, Michal Piotrowski wrote:
> Hi Christoph,
>
> On 07/06/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Will show up shortly at
> http://ftp.kernel.org/pub/linux/kernel/people/christoph/slab-defrag/
>
> I tried to apply this patchset, but wit
On Fri, 8 Jun 2007, Michal Piotrowski wrote:
> Hi Christoph,
>
> On 07/06/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Will show up shortly at
> http://ftp.kernel.org/pub/linux/kernel/people/christoph/slab-defrag/
>
> I tried to apply this patchset, but wit
On Fri, 8 Jun 2007, Mel Gorman wrote:
> In situations where CONFIG_HOLES_IN_ZONES is set (IA64 with VIRTUAL_MEM_MAP),
> there may be cases where pages allocated within a MAX_ORDER_NR_PAGES block
> of pages may not be displayed in /proc/page_owner if the hole is at the
> start of the block. Address
On Fri, Jun 08, 2007 at 09:05:32AM -0700, Jared Hulbert wrote:
> Okay so we need some driver that opens/closes this ROM. This has been
> done from the dcss block device but that doesn't make sense for most
> embedded systems. The MTD allows for this with point(),unpoint().
> That should work just
On Fri, Jun 08, 2007 at 09:11:47AM -0700, Jared Hulbert wrote:
> >On Fri, Jun 08, 2007 at 09:05:32AM -0700, Jared Hulbert wrote:
> >> Okay so we need some driver that opens/closes this ROM. This has been
> >> done from the dcss block device but that doesn't make sense for most
> >> embedded system
On Fri, 8 Jun 2007, Michal Piotrowski wrote:
> bash shared mapping + your script in a loop
> while true; do sudo ./run.sh; done > res3.txt
H... Seems to be triggered from the reclaim path kmem_cache_defrag
rather than the manual triggered one from the script. Taking the slub_lock
on the re
On Fri, 8 Jun 2007, Michal Piotrowski wrote:
> Yes, it does. Thanks!
Ahhh... That leds to the discovery more sysfs problems. I need to make
sure not to be holding locks while calling into sysfs. More cleanup...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
On Fri, 8 Jun 2007, Michal Piotrowski wrote:
> 0xc1081630 is in list_locations (mm/slub.c:3388).
> 3383struct page *page;
> 3384
> 3385if (!atomic_read(&n->nr_slabs))
> 3386continue;
> 3387
> 3388spin_lock_irqs
On Fri, 8 Jun 2007, Christoph Lameter wrote:
> On Fri, 8 Jun 2007, Michal Piotrowski wrote:
>
> > Yes, it does. Thanks!
>
> Ahhh... That leds to the discovery more sysfs problems. I need to make
> sure not to be holding locks while calling into sysfs. More cleanup...
ng the slub_lock. Let sysfs
fend for itself locking wise.
Just protect the essentials: The modifications to the slab lists
and the ref counters of the slabs.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
mm/slub.c | 34 +-
1 file changed, 21 inse
On Thu, 7 Jun 2007, Andrew Morton wrote:
> > +void *iommu_rpool_alloc(unsigned int size, gfp_t flag)
> > +{
> > + if (size == PAGE_SIZE_4K)
> > + return(void *)get_zeroed_page(flag);
> > + else
> > + return kzalloc(size, flag);
> > +}
>
> kmalloc(4k) is pretty efficient an
On Fri, 8 Jun 2007, Keshavamurthy, Anil S wrote:
> In the IOMMU case, we need exactly opposite of what mempool provides,
> i.e we always want to look for the element in the pool and if the pool
> has no element then go to OS as a worst case. This resource pool
> library routines do the same. Again
On Fri, 8 Jun 2007, Keshavamurthy, Anil S wrote:
> > What functionality are you missing in the page allocator? It seems that is
> > does what you want?
> Humm..I basically want to allocate memory during interrupt context and
> expect not to fail. I know this is a hard requirement :)
The page al
On Fri, 8 Jun 2007, Andreas Kleen wrote:
> > That's what kmem_cache_alloc() is for?!?!
>
> Tradtionally that was not allowed in block layer path. Not sure
> it is fully obsolete with the recent dirty tracking work, probably not.
Why was it not allowed? Because interrupts are disabled?
> Beside
On Fri, 8 Jun 2007, Keshavamurthy, Anil S wrote:
> > You _seem_ to be saying that the resource pools are there purely for
> > alloc/free performance reasons. If so, I'd be skeptical: slab is pretty
> > darned fast.
> We need several objects of size say( 4 * sizeof(u64)) and reuse
> them in dma ma
On Fri, 8 Jun 2007, Siddha, Suresh B wrote:
> > If for some reason you really can't do that (and a requirement for
> > allocation-in-interrupt is the only valid reason, really) and if you indeed
> > can demonstrate memory allocation failures with certain workloads then
> > let's take a look at tha
On Sat, 9 Jun 2007, Andi Kleen wrote:
> > Why was it not allowed? Because interrupts are disabled?
>
> Allocating memory during page out under low memory could
> lead to deadlocks. That is because Linux used to make no attempt
> to limit dirty pages for anonymous mappings and then you could
> en
On Sun, 10 Jun 2007, Arjan van de Ven wrote:
> Christoph Lameter wrote:
> > On Fri, 8 Jun 2007, Keshavamurthy, Anil S wrote:
> >
> > > > What functionality are you missing in the page allocator? It seems that
> > > > is does what you want?
> > >
On Mon, 11 Jun 2007, Haavard Skinnemoen wrote:
> While trying to get SLUB debugging to not break DMA on AVR32, I ran
> into this:
This is a known bug in 2.6.22-rc2/rc3. Which version are you running?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
On Mon, 11 Jun 2007, Håvard Skinnemoen wrote:
> On 6/11/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > On Mon, 11 Jun 2007, Haavard Skinnemoen wrote:
> >
> > > While trying to get SLUB debugging to not break DMA on AVR32, I ran
> > > into this:
>
On Mon, 11 Jun 2007, Håvard Skinnemoen wrote:
> On 6/11/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > Ahhh... I see its the same phenomenon as before but triggered by
> > a different cause.
> >
> > If you set the align to 32 then the first kmalloc slabs
On Mon, 11 Jun 2007, Håvard Skinnemoen wrote:
> > Note that I do not get why you would be aligning the objects to 32 bytes.
> > Increasing the smallest cache size wastes a lot of memory. And it is
> > usually advantageous if multiple related objects are in the same cacheline
> > unless you have he
On Mon, 11 Jun 2007, Eric Sesterhenn / Snakebyte wrote:
>
> +unlikely | 40969931| 6228144 __slab_free()@:mm/[EMAIL PROTECTED]
> +unlikely | 47198075|0 __slab_free()@:mm/[EMAIL PROTECTED]
> -likely |0| 47198075 slab_free()@:mm/[EMAIL PROTECTED]
> +unlikely | 47280864|
On Mon, 11 Jun 2007, Håvard Skinnemoen wrote:
> > >
> > > It's not about performance at all, it's about DMA buffers allocated
> > > using kmalloc() getting corrupted. Imagine this:
> >
> > Uhhh... How about using a separate slab for the DMA buffers?
>
> If there were just a few, known drivers th
On Mon, 11 Jun 2007, Håvard Skinnemoen wrote:
> > We should probably make the minimum slab size dependent on
> > ARCH_KMALLOC_MINALIGN. There is no point in having smaller slabs anyways.
> > They will all have the same size.
>
> Sounds reasonable to me.
Trouble is that ARCH_KMALLOC_MINALIGN is i
On Tue, Jun 12, 2007 at 12:40:06AM +0400, Alexey Dobriyan wrote:
> Identical implementations of PTRACE_PEEKDATA go into
> simple_ptrace_peekdata() function.
>
> compile-tested on ~half of archs, playing with gdb on x86_64.
Looks good. Why don't you call it generic_ptrace_peekdata instead of
simp
On Mon, 11 Jun 2007, Keshavamurthy, Anil S wrote:
> Hence, can I assume that the conclusion of this
> discussion is to use kmem_cache_alloc() functions
> to allocate memory in dma_map_{single|sg} API's?
Use the page allocator for page size allocations. If you need to have
specially aligned me
On Tue, 12 Jun 2007, Andi Kleen wrote:
> > If the only option is to panic then something's busted. If it's network IO
> > then there should be a way of dropping the frame. If it's disk IO then we
> > should report the failure and cause an IO error.
>
> An block IO error is basically catastrophi
On Mon, 11 Jun 2007, Keshavamurthy, Anil S wrote:
> slab allocators don;t reserve the memory, in other words this memory
> can be consumed by VM under memory pressure which we don;t want in
> IOMMU case.
So mempools
> Nope,they both are exactly opposite.
> mempool with GFP_ATOMIC, first tr
On Mon, 11 Jun 2007, Arjan van de Ven wrote:
> the problem with that is that if anything downstream from the iommu layer ALSO
> needs memory, we've now eaten up the last free page and things go splat.
Hmmm... We need something like a reservation system right? Higher levels
in a atomic context co
No arch sets ARCH_KMALLOC_MINALIGN larger than 8 though excepts mips which
needs a 128 byte cache.
This patch increases the size of the smallest cache if ARCH_KMALLOC_MINALIGN
is greater than 8. In that case more and more of the smallest caches are
disabled.
Signed-off-by: Christoph Lameter <
On Tue, Jun 12, 2007 at 09:27:18AM +0200, Jan Beulich wrote:
> Kill pte_rdprotect(), pte_exprotect(), pte_mkread(), pte_mkexec(), pte_read(),
> pte_exec(), and pte_user() except where arch-specific code is making use of
> them.
Looks good.
-
To unsubscribe from this list: send the line "unsubscri
On Tue, Jun 12, 2007 at 04:14:39PM -0400, Chris Mason wrote:
> > Aside from folding snapshot history into the origin's namespace... It
> > could be possible to have a mount.btrfs that allows subvolumes and/or
> > snapshot volumes to be mounted as unique roots? I'd imagine a bind
> > mount _could_
On Wed, 13 Jun 2007, Michal Piotrowski wrote:
> Subject: kernel BUG at mm/slub.c:3689!
> References : http://lkml.org/lkml/2007/6/11/121
> Submitter : Haavard Skinnemoen <[EMAIL PROTECTED]>
> Handled-By : Christoph Lameter <[EMAIL PROTECTED]>
> Patch : http://
Independent of any nl80211 status the private libertas ioctls have to
go. Not only don't we want private ioctls for mesh networking but rather
have it as driver-independent interface, but the actual libertas interface
is the worst possible choice. It uses the absolutely broken iwpriv interface
in
On Wed, Jun 13, 2007 at 05:57:59PM +0400, Dmitriy Monakhov wrote:
> Function prerform check for signgle region, with out respect to
> segment nature of iovec, For example writev no longer works :)
Btw, could someone please start to collect all sniplets like this in
a nice simple regres
On Thu, Jun 14, 2007 at 04:36:09PM +0900, Kentaro Takeda wrote:
> We limit the maximum length of any string data (such as domainname and
> pathnames)
> to TOMOYO_MAX_PATHNAME_LEN (which is 4000) bytes to fit within a single
> page.
>
> Userland programs can obtain the amount of RAM currently use
> I suspect that the probability of your proposal succeeding would be increased
> if you could prepare a patch...
Here we go:
Index: linux-2.6/drivers/net/wireless/libertas/Makefile
===
--- linux-2.6.orig/drivers/net/wireless/liberta
On Thu, 14 Jun 2007, Sam Ravnborg wrote:
> We need access to PAGE_SIZE in vmlinux.lds.h.
> What is your plan with that usage?
This is about PAGE_CACHE_xxx. No changes to PAGE__SIZE are planned.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Thu, Jun 14, 2007 at 01:06:45PM -0700, Andrew Morton wrote:
> On Thu, 14 Jun 2007 12:38:39 -0700
> [EMAIL PROTECTED] wrote:
>
> > This patchset cleans up the page cache handling by replacing
> > open coded shifts and adds through inline function calls.
>
> If we never inflict variable PAGE_CAC
On Thu, 14 Jun 2007, Andrew Morton wrote:
> If we never inflict variable PAGE_CACHE_SIZE upon the kernel, these changes
> become pointless obfuscation.
But there is no such resonable scenario that I am aware of unless we
continue to add workarounds for the issues covered here to the VM.
And it
On Thu, 14 Jun 2007, Andrew Morton wrote:
> We want the 100% case.
Yes that is what we intend to do. Universal support for larger blocksize.
I.e. your desktop filesystem will use 64k page size and server platforms
likely much larger. fsck times etc etc are becoming an issue for desktop
systems
On Thu, 14 Jun 2007, Andrew Morton wrote:
> With 64k pagesize the amount of memory required to hold a kernel tree (say)
> will go from 270MB to 1400MB. This is not an optimisation.
I do not think that the 100% users will do kernel compiles all day like
we do. We likely would prefer 4k page siz
On Thu, Jun 14, 2007 at 06:22:35PM -0400, Dan Williams wrote:
> And that's what I did in the last pull you got from John; all pointless
> and duplicated ioctls were removed. The only ones left are mesh
> tweakables, an LED GPIO control ioctl, and a regulatory region/domain
> thing. I agree the in
On Fri, Jun 15, 2007 at 08:21:09AM +1000, David Chinner wrote:
> Yeah, it can run a subset of the tests on NFS and UDF filesystems as well and
> there are some specific UDF-only tests in it too. I think the NFS test group
> is mostly generic tests that don't use or test specific XFS features.
Act
On Fri, Jun 15, 2007 at 12:11:22AM +0100, Alan Cox wrote:
> - Remove the BSD dual licence on the new work
> - Switch the if ALPHA to if __LP64__. (struct size is then right elsewhere)
__LP64__ is not a correct check unfortunately. Please use
CONFIG_64BIT instead.
-
To unsubscribe from this list:
On Thu, 14 Jun 2007, Andrew Morton wrote:
> > I do not think that the 100% users will do kernel compiles all day like
> > we do. We likely would prefer 4k page size for our small text files.
>
> There are many, many applications which use small files.
There is no problem with them using 4k page
On Thu, 14 Jun 2007, Andrew Morton wrote:
> There will be files which should use 64k but which instead end up using 4k.
>
> There will be files which should use 4k but which instead end up using 64k.
>
> Because determining which size to use requires either operator intervention
> or kernel heur
On Thu, 14 Jun 2007, Andrew Morton wrote:
> > The metadata needs to refer to 1/16th of the earlier pages that need to be
> > tracked. metadata is shrunk significantly.
>
> Only if the filesystems are altered to use larger blocksizes and if the
> operator then chooses to use that feature. Then t
On Tue, 12 Jun 2007, Hidetoshi Seto wrote:
>
> [arch/ia64/kernel/time.c]
> > #ifdef CONFIG_SMP
> > /* On IA64 in an SMP configuration ITCs are never accurately synchronized.
> >* Jitter compensation requires a cmpxchg which may limit
> >* the scalability of the syscalls for retrieving t
On Fri, Jun 15, 2007 at 11:20:31AM -0400, Jason Baron wrote:
> hi,
>
> i was just looking at the new madvise_need_mmap_write() call...can we
> avoid an extra case statement and function call as follows?
Sounds like a good idea, but please move the assignment out of the
conditional.
-
To unsubscr
On Fri, Jun 15, 2007 at 01:05:44PM +0200, Jens Axboe wrote:
> On Fri, Jun 15 2007, Tejun Heo wrote:
> > SCSI marks internal commands with REQ_PREEMPT and push it at the front
> > of the request queue using blk_execute_rq(). When entering suspended
> > or frozen state, SCSI devices are quiesced usi
Could you try to boot with "slub_debug" on the kernel command line? That
may help you to diagnose the problem.
-
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
On Sun, 17 Jun 2007, Matt Mackall wrote:
> Is it? Last I looked it had reverted to handing out reverse-contiguous
> pages.
I thought that was fixed? Bill Irwin was working on it.
But the contiguous pages usually only work shortly after boot. After
awhile memory gets sufficiently scrambled that
On Mon, 18 Jun 2007, Paul Mundt wrote:
> On Mon, Jun 18, 2007 at 02:58:42AM -0700, [EMAIL PROTECTED] wrote:
> > So add the necessary logic to all slab allocators to support __GFP_ZERO.
> >
> Does this mean I should update my SLOB NUMA support patch? ;-)
Hehehe. Its not merged yet. Sorry about th
On Mon, 18 Jun 2007, Michal Piotrowski wrote:
> Result:
>
> [ 212.247759] WARNING: at lib/vsprintf.c:280 vsnprintf()
> [ 212.253263] [] dump_trace+0x63/0x1eb
> [ 212.259042] [] show_trace_log_lvl+0x1a/0x2f
> [ 212.266672] [] show_trace+0x12/0x14
> [ 212.271622] [] dump_stack+0x16/0x18
>
On Mon, 18 Jun 2007, Srivatsa Vaddagiri wrote:
> This particular machine, elm3b6, is a 4-cpu, (gasp, yes!) 4-node box i.e
> each CPU is a node by itself. If you don't have CONFIG_NUMA enabled,
> then we won't have cross-node (i.e cross-cpu) load balancing.
> Fortunately in your case you had CONFI
On Mon, 18 Jun 2007, Mel Gorman wrote:
> @@ -632,18 +632,27 @@ static int unmap_and_move(new_page_t get
> goto unlock;
> wait_on_page_writeback(page);
> }
> -
> + /* anon_vma should not be freed while migration. */
> + if (PageAnon(page)) {
> +
preserve existing behaviour, move_pages()
> is only available when CONFIG_NUMA is set.
What does this have to do with memory models? A bit unclear.
Otherwise
Acked-by: Christoph Lameter <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&quo
Acked-by: Christoph Lameter <[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/
Good idea.
Signed-off-by: Christoph Lameter <[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 ht
migrate_pages(&cc->migratepages, compaction_alloc,
> + (unsigned long)cc);
You do not need to check the result of migration? Page migration is a best
effort that may fail.
Looks good otherwise.
Acked-by: Christoph Lameter <[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/
You are amazing.
Acked-by: Christoph Lameter <[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 ht
On Mon, 18 Jun 2007, Mel Gorman wrote:
> The patchset implements memory compaction for the page allocator reducing
> external fragmentation so that free memory exists as fewer, but larger
> contiguous blocks. Instead of being a full defragmentation solution,
> this focuses exclusively on pages tha
On Mon, 18 Jun 2007, Srivatsa Vaddagiri wrote:
> On Mon, Jun 18, 2007 at 09:54:18AM -0700, Christoph Lameter wrote:
> > The nodes-level domain looks for internode balances between up to 16
> > nodes. It is not restricted to a single node.
>
> I was mostly speaking with
E_SIZE
If slabs are allocated or freed from a large set of call sites (typical
for the kmalloc area) then we may create more output than fits into
a single PAGE and sysfs only gives us one page. The output should be
truncated. This patch fixes the checks to do the truncation properly.
Signed-off-b
On Mon, Jun 18, 2007 at 01:24:24AM +0200, Arnd Bergmann wrote:
> On Monday 18 June 2007, Arjan van de Ven wrote:
> >
> > On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote:
> > > This changes asm() to __asm__() and volatile to __volatile__ so that these
> > > headers can be used with gcc's -s
On Mon, Jun 18, 2007 at 08:27:15AM -0600, Robert Hancock wrote:
> If we expect userspace apps to include them, then I would vote for no,
> not for anything outside of #ifdef __KERNEL__ in exported headers. Keep
> in mind also that C++ apps may need to include these as well and those
> extensions
On Sun, Jun 17, 2007 at 06:33:28PM -0400, Mike Frysinger wrote:
> This changes asm() to __asm__() and volatile to __volatile__ so that these
> headers can be used with gcc's -std=c99.
We should not allow inline assemly in the exported part of userspace headers
at all. These headers must only incl
On Mon, Jun 18, 2007 at 10:02:21AM -0400, Mike Frysinger wrote:
> > This is wrong for two reasons:
> >
> > - MSRs are not accessible in user space.
> > - .section .fixup is not applicable to user space.
> >
> > Anything MSR-related should be protected by __KERNEL__ instead.
> >
> > This NAK doesn't
On Mon, Jun 18, 2007 at 02:19:10AM -0400, Mike Frysinger wrote:
> Since asm-ia64/gcc_intrin.h gets exported to userspace, we need to make sure
> to use __asm__() rather than asm() since the latter is not available when
> compiling with gcc with GNU extensions turned off (like -std=c99).
This heade
On Mon, Jun 18, 2007 at 07:34:50PM +0100, Christoph Hellwig wrote:
> On Sun, Jun 17, 2007 at 06:33:28PM -0400, Mike Frysinger wrote:
> > This changes asm() to __asm__() and volatile to __volatile__ so that these
> > headers can be used with gcc's -std=c99.
>
> We shoul
On Mon, Jun 18, 2007 at 11:59:30AM -0400, Robert P. J. Day wrote:
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
>
> ---
>
> this appears to be the final occurrence of that deprecated call in
> the entire tree which suggests that, if you're not concerned about
> out-of-tree modules, t
On Mon, Jun 18, 2007 at 01:38:47PM -0400, Dan Williams wrote:
> On Thu, 2007-06-14 at 19:13 +0100, Christoph Hellwig wrote:
> > > I suspect that the probability of your proposal succeeding would be
> > > increased
> > > if you could prepare a patch...
>
>
On Mon, 18 Jun 2007, Michal Piotrowski wrote:
> Still the same.
Is it still exactly the same strack trace? There could be multiple issue
if we overflow PAGE_SIZE there.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More m
kmalloc area) then we may create more output than fits into
a single PAGE and sysfs only gives us one page. The output should be
truncated. This patch fixes the checks to do the truncation properly.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6.22-rc4-mm2/mm/
I think we are getting into more and more of a mess with the existing
memory policies. The refcount issue with shmem is just one bad symptom of
it. Memory policies were intended to be process based and
taking them out of that context causes various issues.
I have thought for a long time that we
On Mon, 18 Jun 2007, Pekka Enberg wrote:
> 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 s
On Mon, 18 Jun 2007, Pekka Enberg wrote:
> 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 co
On Mon, 18 Jun 2007, Thomas Glanzmann wrote:
> Hello,
> a friend of mine always builds the Debian Packages from unstable for
> Debian Etch. I have on all my machines the following line in
> /etc/apt/sources.list:
>
> deb http://rmdir.de/~michael/git/ ./
>
> apt-get update; apt-get dist-u
On Mon, 18 Jun 2007, Siddha, Suresh B wrote:
> > + if (time_after(next_balance,
> > + sd->last_balance + sd->balance_interval))
> > + next_balance = sd->last_balance
> > + + sd->balance_interval;
>
> don't we have t
On Mon, Jun 18, 2007 at 09:00:09PM +0200, Sam Ravnborg wrote:
> Do you imply that if we see asm or __asm__ in user space headers we ougth
> to warn about it?
> Seems at least sensible to me but if we introduce such a check we should
> kill all offenders first - which Mike's patches seems to trigger
Looks pretty nice.
Some more comments:
- no need for the BLK_DEV_SR dependency, it should depend on SCSI
instead (which might be implied by beeing in the scsi menu, don't
remember that detail)
- ps3rom_priv should probably be an inline
- the cmd field in struct ps3rom_private should pro
On Fri, Jun 15, 2007 at 02:19:17PM -0700, David Miller wrote:
> Another quirk I have to deal with is that under LDOMs you
> can export full disks and also just slices. So I'll have
> to get down into the partition machinery to support that
> somehow.
What's the problem with that? Partition machi
On Fri, Jun 15, 2007 at 01:39:23PM +0200, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven <[EMAIL PROTECTED]>
>
> Add a Disk Storage Driver for the PS3:
> - Implemented as a block device driver with a dynamic major
> - Disk names (and partitions) are of the format ps3d%c(%u)
> - Uses so
On Fri, Jun 15, 2007 at 04:08:58PM -0700, David Miller wrote:
> That's not gonna work, it's a totally different model.
>
> I have a predefined protocol over hypervisor provided "channels" and
> page flipping also done by the hypervisor for the bulk data transfer.
> For the client side I cannot cha
On Mon, Jun 18, 2007 at 11:07:31PM -0700, David Miller wrote:
> The main disk I/O block read and write is done using descriptors
> sent to the disk server. SCSI pass-through is provided (optionally)
> so that disk analysis tools can do things like MODE_SENSE on the
> disk.
SG_IO can easily be imp
On Tue, Jun 19, 2007 at 02:51:25PM +0200, Geert Uytterhoeven wrote:
> On Tue, 19 Jun 2007, Christoph Hellwig wrote:
> > On Fri, Jun 15, 2007 at 01:39:23PM +0200, Geert Uytterhoeven wrote:
> > > From: Geert Uytterhoeven <[EMAIL PROTECTED]>
> > >
> >
On Sun, Jun 17, 2007 at 02:47:04PM +0200, Geert Uytterhoeven wrote:
> Hi James,
>
> These patches add support for m68k to the 53c700 SCSI core and introduce new
> drivers for various m68k hardware using this 53c700 SCSI core, to replace the
> just removed drivers using the old 53c7xx SCSI co
("nsproxy", sizeof(struct nsproxy),
> > + 0, SLAB_PANIC, NULL, NULL);
> > + return 0;
> > +}
> > +
>
> Christoph added this cheesy KMEM_CACHE macro. But I don't immediately recall
> the rationale so I'm a bit reluctant to a
On Tue, Jun 19, 2007 at 05:15:56PM +0100, Paulo Marques wrote:
>
> The only in-kernel user of "memmem" is scripts/kallsyms.c and it only
> uses it to find tokens that are 2 bytes in size. It is trivial to
> replace it with a simple function that finds 2-byte tokens.
>
> This should help users f
1 - 100 of 5504 matches
Mail list logo
