From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx197.postini.com [74.125.245.197]) by kanga.kvack.org (Postfix) with SMTP id 575726B002B for ; Thu, 11 Oct 2012 11:25:35 -0400 (EDT) Message-ID: <5076E4B2.2040301@redhat.com> Date: Thu, 11 Oct 2012 11:24:34 -0400 From: Rik van Riel MIME-Version: 1.0 Subject: Re: [PATCH 07/33] autonuma: mm_autonuma and task_autonuma data structures References: <1349308275-2174-1-git-send-email-aarcange@redhat.com> <1349308275-2174-8-git-send-email-aarcange@redhat.com> <20121011122827.GT3317@csn.ul.ie> In-Reply-To: <20121011122827.GT3317@csn.ul.ie> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Mel Gorman Cc: Andrea Arcangeli , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Linus Torvalds , Andrew Morton , Peter Zijlstra , Ingo Molnar , Hugh Dickins , Johannes Weiner , Hillf Danton , Andrew Jones , Dan Smith , Thomas Gleixner , Paul Turner , Christoph Lameter , Suresh Siddha , Mike Galbraith , "Paul E. McKenney" , Lai Jiangshan , Bharata B Rao , Lee Schermerhorn , Srivatsa Vaddagiri , Alex Shi , Mauricio Faria de Oliveira , Konrad Rzeszutek Wilk , Don Morris , Benjamin Herrenschmidt On 10/11/2012 08:28 AM, Mel Gorman wrote: >> + /* link for knuma_scand's list of mm structures to scan */ >> + struct list_head mm_node; >> + /* Pointer to associated mm structure */ >> + struct mm_struct *mm; >> + >> + /* >> + * Zeroed from here during allocation, check >> + * mm_autonuma_reset() if you alter the below. >> + */ >> + >> + /* >> + * Pass counter for this mm. This exist only to be able to >> + * tell when it's time to apply the exponential backoff on the >> + * task_autonuma statistics. >> + */ >> + unsigned long mm_numa_fault_pass; >> + /* Total number of pages that will trigger NUMA faults for this mm */ >> + unsigned long mm_numa_fault_tot; >> + /* Number of pages that will trigger NUMA faults for each [nid] */ >> + unsigned long mm_numa_fault[0]; >> + /* do not add more variables here, the above array size is dynamic */ >> +}; > > How cache hot is this structure? nodes are sharing counters in the same > cache lines so if updates are frequent this will bounce like a mad yoke. > Profiles will tell for sure but it's possible that some sort of per-cpu > hilarity will be necessary here in the future. These statistics are updated at page fault time, I believe while holding the page table lock. In other words, they are in code paths where updating the stats should not cause issues. >> +/* >> + * Per-task (thread) structure that contains the NUMA memory placement >> + * statistics generated by the knuma scan daemon. This structure is >> + * dynamically allocated only if AutoNUMA is possible on this >> + * system. They are linked togehter in a list headed within the >> + * knumad_scan structure. >> + */ >> +struct task_autonuma { >> + unsigned long task_numa_fault[0]; >> + /* do not add more variables here, the above array size is dynamic */ >> +}; >> + > > Same question about cache hotness. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org