Re: [PATCHv3 04/24] rmap: add argument to charge compound page

[Rik van Riel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/12/2015 11:18 AM, Kirill A. Shutemov wrote:

> +++ b/include/linux/rmap.h @@ -168,16 +168,24 @@ static inline void
> anon_vma_merge(struct vm_area_struct *vma,
> 
> struct anon_vma *page_get_anon_vma(struct page *page);
> 
> +/* flags for do_page_add_anon_rmap() */ +enum { +	RMAP_EXCLUSIVE =
> 1, +	RMAP_COMPOUND = 2, +};

Always a good idea to name things. However, "exclusive" is
not that clear to me. Given that the argument is supposed
to indicate whether we map a single or a compound page,
maybe the names in the enum could just be SINGLE and COMPOUND?

Naming the enum should make it clear enough what it does:

 enum rmap_page {
      SINGLE = 0,
      COMPOUND
 }

> +++ b/kernel/events/uprobes.c @@ -183,7 +183,7 @@ static int
> __replace_page(struct vm_area_struct *vma, unsigned long addr, goto
> unlock;
> 
> get_page(kpage); -	page_add_new_anon_rmap(kpage, vma, addr); +
> page_add_new_anon_rmap(kpage, vma, addr, false); 
> mem_cgroup_commit_charge(kpage, memcg, false); 
> lru_cache_add_active_or_unevictable(kpage, vma);

Would it make sense to use the name in the argument to that function,
too?

I often find it a lot easier to see what things do if they use symbolic
names, rather than by trying to remember what each boolean argument to
a function does.

- -- 
All rights reversed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU3Ra9AAoJEM553pKExN6D4UcH/10GlcYBB813KE7dR2r23MDx
WlrcC096IRoEjD/aaBHikLcKSu5mZDzf3ic1ZHzMPzz7oMdsFkmnY/k2zMdcqc83
7scvd7VB3acI4STKWcbkaCsIHIpHPFmfdcLv9Rabi0P2MBb8SALQCwxDUJqvXojC
JdJivfuagDoSUEamHwZrCvFylC7J7M4zPLD5aUpc93E4I4lhG9VHD7FmnYP3rxb8
kX4DOZFZ7aTN3K9IweCZPN2HWZe2qcSKc/AmIfHfokdjJLTuqbMv5UGSwLHmmeDf
DO4Uru/BMgPg2Ds7uKZosf7icAnOzT08b/Woh34JT83ua9XpFMam+hx6g+lA78E=
=Kzss
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/