lkml.org 
[lkml]   [2015]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mm, memcg: sync allocation and memcg charge gfp flags for THP
On Wed 18-03-15 16:40:34, Vlastimil Babka wrote:
> On 03/18/2015 04:02 PM, Michal Hocko wrote:
> >On Wed 18-03-15 15:34:50, Vlastimil Babka wrote:
> >>On 03/16/2015 03:08 PM, Michal Hocko wrote:
> >>>@@ -1080,6 +1080,7 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct *vma,
> >>> unsigned long haddr;
> >>> unsigned long mmun_start; /* For mmu_notifiers */
> >>> unsigned long mmun_end; /* For mmu_notifiers */
> >>>+ gfp_t huge_gfp = GFP_TRANSHUGE; /* for allocation and charge */
> >>
> >>This value is actually never used. Is it here because the compiler emits a
> >>spurious non-initialized value warning otherwise? It should be easy for it
> >>to prove that setting new_page to something non-null implies initializing
> >>huge_gfp (in the hunk below), and NULL new_page means it doesn't reach the
> >>mem_cgroup_try_charge() call?
> >
> >No, I haven't tried to workaround the compiler. It just made the code
> >more obvious to me. I can remove the initialization if you prefer, of
> >course.
>
> Yeah IMHO it would be better to remove it, if possible. Leaving it has the
> (albeit small) chance that future patch will again use the value in the code
> before it's determined based on defrag setting.

Wouldn't an uninitialized value be used in such a case?

--
Michal Hocko
SUSE Labs


\
 
 \ /
  Last update: 2015-03-18 17:21    [W:1.095 / U:0.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site