lkml.org 
[lkml]   [2016]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] proc: mm: export PTE sizes directly in smaps (v3)
On Tue, Nov 29, 2016 at 10:17 PM, Dave Hansen <dave@sr71.net> wrote:
>
> Andrew, you can drop proc-mm-export-pte-sizes-directly-in-smaps-v2.patch,
> and replace it with this.

You added a warning and it immediately appears:


[ 0.402603] ------------[ cut here ]------------
[ 0.402844] WARNING: CPU: 0 PID: 1 at
/home/andy/prj/linux-netboot/mm/hugetlb.c:2918
hugetlb_add_hstate+0x143/0
x14b
[ 0.403042] Modules linked in:
[ 0.403233] CPU: 0 PID: 1 Comm: swapper Not tainted
4.9.0-rc7-next-20161201+ #1
[ 0.403499] Call Trace:
[ 0.403677] dump_stack+0x16/0x1d
[ 0.404081] __warn+0xd1/0xf0
[ 0.404289] ? hugetlb_add_hstate+0x143/0x14b
[ 0.404491] warn_slowpath_null+0x25/0x30
[ 0.404695] hugetlb_add_hstate+0x143/0x14b
[ 0.404908] hugetlb_init+0x79/0x3af
[ 0.405249] ? wake_up_process+0xf/0x20
[ 0.405450] ? kcompactd_run+0x50/0x90
[ 0.405638] ? compact_zone+0x7c0/0x7c0
[ 0.405842] ? hugetlb_add_hstate+0x14b/0x14b
[ 0.406082] do_one_initcall+0x2f/0x160
[ 0.406286] ? repair_env_string+0x12/0x54
[ 0.406482] ? parse_args+0x2a1/0x5a0
[ 0.406684] ? __dquot_free_space+0xa0/0x2d0
[ 0.406892] ? kernel_init_freeable+0xe4/0x18a
[ 0.407088] kernel_init_freeable+0x107/0x18a
[ 0.407303] ? rest_init+0x60/0x60
[ 0.407496] kernel_init+0xb/0x100
[ 0.407703] ? schedule_tail_wrapper+0x9/0x10
[ 0.408099] ret_from_fork+0x19/0x30
[ 0.408302] ---[ end trace 601ba77b9b62b9d7 ]---
[ 0.408481] HugeTLB registered 4 MB page size, pre-allocated 0 pages


Quark SoC here.

Besides that see below.

> +/*
> + * What units should we use for a given number? We want
> + * 2048 to be 2k, so we return 'k'. 1048576 should be
> + * 1M, so we return 'M'.
> + */
> +static char size_unit(unsigned long long nr)
> +{
> + /*
> + * This ' ' might look a bit goofy in the output. But, why
> + * bother doing anything. Do we even have a <1k page size?
> + */
> + if (nr < (1ULL<<10))
> + return ' ';
> + if (nr < (1ULL<<20))
> + return 'k';
> + if (nr < (1ULL<<30))
> + return 'M';
> + if (nr < (1ULL<<40))
> + return 'G';
> + if (nr < (1ULL<<50))
> + return 'T';
> + if (nr < (1ULL<<60))
> + return 'P';
> + return 'E';
> +}
> +
> +/*
> + * How should we shift down a a given number to scale it
> + * with the units we are printing it as? 2048 to be 2k,
> + * so we want it shifted down by 10. 1048576 should be
> + * 1M, so we want it shifted down by 20.
> + */
> +static int size_shift(unsigned long long nr)
> +{
> + if (nr < (1ULL<<10))
> + return 0;
> + if (nr < (1ULL<<20))
> + return 10;
> + if (nr < (1ULL<<30))
> + return 20;
> + if (nr < (1ULL<<40))
> + return 30;
> + if (nr < (1ULL<<50))
> + return 40;
> + if (nr < (1ULL<<60))
> + return 50;
> + return 60;
> +}
> +

New copy of string_get_size() ?

Something similar was discussed for EFI stuff like half a year ago?

> +static void show_one_smap_pte(struct seq_file *m, unsigned long bytes_rss,
> + unsigned long pte_size)
> +{
> + seq_printf(m, "Ptes@%ld%cB: %8lu kB\n",
> + pte_size >> size_shift(pte_size),
> + size_unit(pte_size),
> + bytes_rss >> 10);
> +}


> + /*
> + * PGD_SIZE isn't widely made available by architecures,
> + * so use PUD_SIZE*PTRS_PER_PUD as a substitute.
> + *
> + * Check for sizes that might be mapped by a PGD. There
> + * are none of these known today, but be on the lookout.
> + * If this trips, we will need to update the mss->rss_*
> + * code in fs/proc/task_mmu.c.
> + */
> + WARN_ON_ONCE((PAGE_SIZE << order) >= PUD_SIZE * PTRS_PER_PUD);

This what I got.

--
With Best Regards,
Andy Shevchenko

\
 
 \ /
  Last update: 2016-12-01 15:51    [W:0.086 / U:0.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site