headers
H. Peter Anvin | 1 Jun 2011 01:16
Favicon

Re: [slubllv5 07/25] x86: Add support for cmpxchg_double

On 05/31/2011 09:53 AM, Christoph Lameter wrote:
> Index: linux-2.6/arch/x86/Kconfig.cpu
> ===================================================================
> --- linux-2.6.orig/arch/x86/Kconfig.cpu	2011-05-31 11:28:24.202948792 -0500
> +++ linux-2.6/arch/x86/Kconfig.cpu	2011-05-31 11:29:36.742948327 -0500
>  <at>  <at>  -312,6 +312,16  <at>  <at>  config X86_CMPXCHG
>  config CMPXCHG_LOCAL
>  	def_bool X86_64 || (X86_32 && !M386)
> 
> +#
> +# CMPXCHG_DOUBLE needs to be set to enable the kernel to use cmpxchg16/8b
> +# for cmpxchg_double if it find processor flags that indicate that the
> +# capabilities are available. CMPXCHG_DOUBLE only compiles in
> +# detection support. It needs to be set if there is a chance that processor
> +# supports these instructions.
> +#
> +config CMPXCHG_DOUBLE
> +	def_bool GENERIC_CPU || X86_GENERIC || !M386
> +
>  config X86_L1_CACHE_SHIFT
>  	int
>  	default "7" if MPENTIUM4 || MPSC

Per previous discussion:

- Drop this Kconfig option (it is irrelevant.)  CONFIG_CMPXCHG_LOCAL is
different: it indicates that CMPXCHG is *guaranteed* to exist.

> +	asm volatile(LOCK_PREFIX_HERE "cmpxchg8b (%%esi); setz %1"\
> +		       : "d="(__dummy), "=a" (__ret) 		\
(Continue reading)

Permalink | Reply | 7 comments |
headers
Christoph Lameter | 1 Jun 2011 01:49
Picon

Re: [slubllv5 07/25] x86: Add support for cmpxchg_double

On Tue, 31 May 2011, H. Peter Anvin wrote:

> On 05/31/2011 09:53 AM, Christoph Lameter wrote:
> > Index: linux-2.6/arch/x86/Kconfig.cpu
> > ===================================================================
> > --- linux-2.6.orig/arch/x86/Kconfig.cpu	2011-05-31 11:28:24.202948792 -0500
> > +++ linux-2.6/arch/x86/Kconfig.cpu	2011-05-31 11:29:36.742948327 -0500
> >  <at>  <at>  -312,6 +312,16  <at>  <at>  config X86_CMPXCHG
> >  config CMPXCHG_LOCAL
> >  	def_bool X86_64 || (X86_32 && !M386)
> >
> > +#
> > +# CMPXCHG_DOUBLE needs to be set to enable the kernel to use cmpxchg16/8b
> > +# for cmpxchg_double if it find processor flags that indicate that the
> > +# capabilities are available. CMPXCHG_DOUBLE only compiles in
> > +# detection support. It needs to be set if there is a chance that processor
> > +# supports these instructions.
> > +#
> > +config CMPXCHG_DOUBLE
> > +	def_bool GENERIC_CPU || X86_GENERIC || !M386
> > +
> >  config X86_L1_CACHE_SHIFT
> >  	int
> >  	default "7" if MPENTIUM4 || MPSC
>
> Per previous discussion:
>
> - Drop this Kconfig option (it is irrelevant.)  CONFIG_CMPXCHG_LOCAL is
> different: it indicates that CMPXCHG is *guaranteed* to exist.
(Continue reading)

Permalink | Reply | 6 comments |
headers
H. Peter Anvin | 1 Jun 2011 01:54
Favicon

Re: [slubllv5 07/25] x86: Add support for cmpxchg_double

On 05/31/2011 04:49 PM, Christoph Lameter wrote:
>>>
>>> +#
>>> +# CMPXCHG_DOUBLE needs to be set to enable the kernel to use cmpxchg16/8b
>>> +# for cmpxchg_double if it find processor flags that indicate that the
>>> +# capabilities are available. CMPXCHG_DOUBLE only compiles in
>>> +# detection support. It needs to be set if there is a chance that processor
>>> +# supports these instructions.
>>> +#
>>> +config CMPXCHG_DOUBLE
>>> +	def_bool GENERIC_CPU || X86_GENERIC || !M386
>>> +
>>>  config X86_L1_CACHE_SHIFT
>>>  	int
>>>  	default "7" if MPENTIUM4 || MPSC
>>
>> Per previous discussion:
>>
>> - Drop this Kconfig option (it is irrelevant.)  CONFIG_CMPXCHG_LOCAL is
>> different: it indicates that CMPXCHG is *guaranteed* to exist.
> 
> Right but this is for cmpxchg16b which means that we need to check a
> bit in the processor flags. Isnt this what you suggested?
> 

Per your own description:

"CMPXCHG_DOUBLE only compiles in detection support. It needs to be set
if there is a chance that processor supports these instructions."
(Continue reading)

Permalink | Reply | 5 comments |
headers
Brad Campbell | 1 Jun 2011 02:18

Re: KVM induced panic on 2.6.38[2367] & 2.6.39

On 01/06/11 06:31, Hugh Dickins wrote:
>
> Brad, my suspicion is that in each case the top 16 bits of RDX have been
> mysteriously corrupted from ffff to 0000, causing the general protection
> faults.  I don't understand what that has to do with KSM.

No, nor do I. The panic I reproduced with KSM off was in a completely 
unrelated code path. To be honest I would not be surprised if it turns 
out I have dodgy RAM, although it has passed multiple memtests and I've 
tried clocking it down. Just a gut feeling.

> But it's only a suspicion, because I can't make sense of the "Code:"
> lines in your traces, they have more than the expected 64 bytes, and
> only one of them has a ">" (with no"<") to mark faulting instruction.

Yeah, with hindsight I must have removed them when I re-formatted the 
code from the oops. Each byte was one line in the syslog so there was a 
lot of deleting to get it to a postable format.

> I did try compiling the 2.6.39 kernel from your config, but of course
> we have different compilers, so although I got close, it wasn't exact.
>
> Would you mind mailing me privately (it's about 73MB) the "objdump -trd"
> output for your original vmlinux (with KSM on)?  (Those -trd options are
> the ones I'm used to typing, I bet not they're not all relevant.)
>
> Of course, it's only a tiny fraction of that output that I need,
> might be better to cut it down to remove_rmap_item_from_tree and
> dup_fd and ksm_scan_thread, if you have the time to do so.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brad Campbell | 1 Jun 2011 02:37

Re: KVM induced panic on 2.6.38[2367] & 2.6.39

On 01/06/11 06:31, Hugh Dickins wrote:
> Brad, my suspicion is that in each case the top 16 bits of RDX have been
> mysteriously corrupted from ffff to 0000, causing the general protection
> faults.  I don't understand what that has to do with KSM.
>
> But it's only a suspicion, because I can't make sense of the "Code:"
> lines in your traces, they have more than the expected 64 bytes, and
> only one of them has a ">" (with no"<") to mark faulting instruction.
>
> I did try compiling the 2.6.39 kernel from your config, but of course
> we have different compilers, so although I got close, it wasn't exact.
>
> Would you mind mailing me privately (it's about 73MB) the "objdump -trd"
> output for your original vmlinux (with KSM on)?  (Those -trd options are
> the ones I'm used to typing, I bet not they're not all relevant.)
>
> Of course, it's only a tiny fraction of that output that I need,
> might be better to cut it down to remove_rmap_item_from_tree and
> dup_fd and ksm_scan_thread, if you have the time to do so.

Would you believe about 20 seconds after I pressed send the kernel oopsed.

http://www.fnarfbargle.com/private/003_kernel_oops/

oops reproduced here, but an un-munged version is in that directory 
alongside the kernel.

[36542.880228] general protection fault: 0000 [#1] SMP
[36542.880271] last sysfs file: 
/sys/devices/pci0000:00/0000:00:18.3/temp1_input
(Continue reading)

Permalink | Reply | 40 comments |
headers
Christoph Hellwig | 1 Jun 2011 02:39
Favicon

Re: [PATCH 3/14] tmpfs: take control of its truncate_range

> Note that drivers/gpu/drm/i915/i915_gem.c i915_gem_object_truncate()
> calls the tmpfs ->truncate_range directly: update that in a separate
> patch later, for now just let it duplicate the truncate_inode_pages().
> Because i915 handles unmap_mapping_range() itself at a different stage,
> we have chosen not to bundle that into ->truncate_range.

In your next series that makes it call the readpae replacement directly
it might be nice to also call directly into shmem for hole punching.

> I notice that ext4 is now joining ocfs2 and xfs in supporting fallocate
> FALLOC_FL_PUNCH_HOLE: perhaps they should support truncate_range, and
> tmpfs should support fallocate?  But worry about that another time...

No, truncate_range and the madvice interface are pretty sad hacks that
should never have been added in the first place.  Adding
FALLOC_FL_PUNCH_HOLE support for shmem on the other hand might make
some sense.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont <at> kvack.org"> email <at> kvack.org </a>
Permalink | Reply | 3 comments |
headers
Christoph Hellwig | 1 Jun 2011 02:42
Favicon

Re: [PATCH 4/14] tmpfs: add shmem_read_mapping_page_gfp

> (shmem_read_mapping_page_gfp or shmem_read_cache_page_gfp?  Generally
> the read_mapping_page functions use the mapping's ->readpage, and the
> read_cache_page functions use the supplied filler, so I think
> read_cache_page_gfp was slightly misnamed.)

What about just shmem_read_page?  It's not using the pagecache, so
no need for the mapping or cache, and the _gfp really is just a hack
because the old pagecache APIs didn't allow to pass the gfp flags.
For a new API there's no need for that.

> +static inline struct page *shmem_read_mapping_page(
> +				struct address_space *mapping, pgoff_t index)
> +{
> +	return shmem_read_mapping_page_gfp(mapping, index,
> +				mapping_gfp_mask(mapping));
> +}

This really shouldn't be in pagemap.h.  For now probably in shmem_fs.h

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont <at> kvack.org"> email <at> kvack.org </a>
Permalink | Reply | 1 comment |
headers
Christoph Hellwig | 1 Jun 2011 02:43
Favicon

Re: [PATCH 7/14] drm/i915: adjust to new truncate_range

>  	/* Our goal here is to return as much of the memory as
>  	 * is possible back to the system as we are called from OOM.
>  	 * To do this we must instruct the shmfs to drop all of its
> -	 * backing pages, *now*. Here we mirror the actions taken
> -	 * when by shmem_delete_inode() to release the backing store.
> +	 * backing pages, *now*.
>  	 */
>  	inode = obj->base.filp->f_path.dentry->d_inode;
> -	truncate_inode_pages(inode->i_mapping, 0);
>  	if (inode->i_op->truncate_range)
>  		inode->i_op->truncate_range(inode, 0, (loff_t)-1);
> +	else
> +		truncate_inode_pages(inode->i_mapping, 0);

Given that it relies on beeing on shmemfs it should just call it
directly.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont <at> kvack.org"> email <at> kvack.org </a>
Permalink | Reply | 1 comment |
headers
Mel Gorman | 1 Jun 2011 02:57
Picon

Re: [PATCH] mm: compaction: Abort compaction if too many pages are isolated and caller is asynchronous

On Tue, May 31, 2011 at 04:14:02PM +0200, Andrea Arcangeli wrote:
> On Tue, May 31, 2011 at 10:33:40PM +0900, Minchan Kim wrote:
> > I checked them before sending patch but I got failed to find strange things. :(
> 
> My review also doesn't show other bugs in migrate_pages callers like
> that one.
> 
> > Now I am checking the page's SwapBacked flag can be changed
> > between before and after of migrate_pages so accounting of NR_ISOLATED_XX can
> > make mistake. I am approaching the failure, too. Hmm.
> 
> When I checked that, I noticed the ClearPageSwapBacked in swapcache if
> radix insertion fails, but that happens before adding the page in the
> LRU so it shouldn't have a chance to be isolated.
> 

After hammering three machines for several hours, I managed to trigger
this once on x86 !CONFIG_SMP CONFIG_PREEMPT HIGHMEM4G (so no PAE)
and caught the following trace.

May 31 23:45:37 arnold kernel: WARNING: at include/linux/vmstat.h:167 compact_zone+0xf8/0x53c()
May 31 23:45:37 arnold kernel: Hardware name:  
May 31 23:45:37 arnold kernel: Modules linked in: 3c59x mii sr_mod forcedeth cdrom ext4 mbcache jbd2 crc16
sd_mod ata_generic pata_amd sata_nv libata scsi_mod
May 31 23:45:37 arnold kernel: Pid: 16172, comm: usemem Not tainted 2.6.38.4-autobuild #17
May 31 23:45:37 arnold kernel: Call Trace:
May 31 23:45:37 arnold kernel: [<c10277f5>] ? warn_slowpath_common+0x65/0x7a
May 31 23:45:37 arnold kernel: [<c1098b12>] ? compact_zone+0xf8/0x53c
May 31 23:45:37 arnold kernel: [<c1027819>] ? warn_slowpath_null+0xf/0x13
May 31 23:45:37 arnold kernel: [<c1098b12>] ? compact_zone+0xf8/0x53c
(Continue reading)

Permalink | Reply | 24 comments |
headers
Andrea Arcangeli | 1 Jun 2011 03:15
Picon
Favicon

Re: KVM induced panic on 2.6.38[2367] & 2.6.39

Hello,

On Wed, Jun 01, 2011 at 08:37:25AM +0800, Brad Campbell wrote:
> On 01/06/11 06:31, Hugh Dickins wrote:
> > Brad, my suspicion is that in each case the top 16 bits of RDX have been
> > mysteriously corrupted from ffff to 0000, causing the general protection
> > faults.  I don't understand what that has to do with KSM.
> >
> > But it's only a suspicion, because I can't make sense of the "Code:"
> > lines in your traces, they have more than the expected 64 bytes, and
> > only one of them has a ">" (with no"<") to mark faulting instruction.
> >
> > I did try compiling the 2.6.39 kernel from your config, but of course
> > we have different compilers, so although I got close, it wasn't exact.
> >
> > Would you mind mailing me privately (it's about 73MB) the "objdump -trd"
> > output for your original vmlinux (with KSM on)?  (Those -trd options are
> > the ones I'm used to typing, I bet not they're not all relevant.)
> >
> > Of course, it's only a tiny fraction of that output that I need,
> > might be better to cut it down to remove_rmap_item_from_tree and
> > dup_fd and ksm_scan_thread, if you have the time to do so.
> 
> Would you believe about 20 seconds after I pressed send the kernel oopsed.
> 
> http://www.fnarfbargle.com/private/003_kernel_oops/
> 
> oops reproduced here, but an un-munged version is in that directory 
> alongside the kernel.
>
(Continue reading)

Permalink | Reply | 39 comments |

Gmane