From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.8 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 065A8C3A59D for ; Thu, 22 Aug 2019 08:43:03 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B09A321848 for ; Thu, 22 Aug 2019 08:43:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lqXinUcC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B09A321848 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=fail smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.92) (envelope-from ) id 1i0ifv-0006D2-1K; Thu, 22 Aug 2019 04:42:31 -0400 Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1i0ifs-0006Cw-DW for kernelnewbies@kernelnewbies.org; Thu, 22 Aug 2019 04:42:28 -0400 Received: by mail-pf1-x430.google.com with SMTP id i30so3460589pfk.9 for ; Thu, 22 Aug 2019 01:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=NU/NpESuWaIYdJLtmDPrYqkzPYspjZDU6qwoq2/RiYI=; b=lqXinUcC03VCl/DXvXxZ7gcTNtM59oU1lIuEqDxgAmj4F0FWEpN95UkVOAxcNeyEpe 4pDGatwchNlO+F0iplh7lCESmn3bjbFb62Bg89CKv97p1ijGMRPO3gJhPdyC0X5xj+VC HJIBpnhWwWXi1utftfvjDM2oK2Hk/eUNiy9qogTOirKFrWClB9Nu3JXEW4IH4TVpgcsr q4Ob52qrZbjr1cvtLd8IiC4d9RGwiyDo/7oZLo2YkWgklwWp6vIXZVGf15asOoi1QtXz PkPG+PzW1lRHxJZOkJs8qrwy3HRRye3KzhE/3YtmCLgFg8rmI/YTvUjnomJYDTVK8V3O nqKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=NU/NpESuWaIYdJLtmDPrYqkzPYspjZDU6qwoq2/RiYI=; b=GmfGOY8uDJEXt/atJnSSwxwmGU22/X+2HltEHEnxNhvtw+MbKciooYJm/ZgPUXPkpJ /WMgoiTLJrJdMbQsT0LpkDBsqzWL2+DQW1/FcIGf3iRwy6mEgyKbS7w14xXrJdp5euaN nd2cVVbBeW1OO7wt6bld8Jk+EFlUX2j77BPtYZ/YGaqLhApB7eOi1CRc1p01WWxUlW3t 9/PqUgVK6tHFi8A5CjrLp7x7Ct8hcB+I6mahqdJrMijW9FCGvexXSfnex16Wl8NvKYgy XzO0GLoq0EQqdGnyyMjLAQBv1LMMZTNrKdLkMf+BTFSvmqiWbq/+b9aFdT0Af9th3not EOTA== X-Gm-Message-State: APjAAAU6d58O3iaVJjKzy65Mh7mQ7yvYgeaCQR3Soh84xyP9OZSfoyE5 AsVqTW1WCB4jzCLDblXtSPKPbXRz X-Google-Smtp-Source: APXvYqwgKoDq6vubHGW9mLEcV09S4MfbWkTWMbSn+APVx8fEfRMBPkZCdPeBmNV9pGIURleZjNjltQ== X-Received: by 2002:a17:90a:9f01:: with SMTP id n1mr4155458pjp.103.1566463286444; Thu, 22 Aug 2019 01:41:26 -0700 (PDT) Received: from swarm01.ajou.ac.kr ([210.107.197.111]) by smtp.gmail.com with ESMTPSA id v27sm44229476pgn.76.2019.08.22.01.41.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Aug 2019 01:41:26 -0700 (PDT) Date: Thu, 22 Aug 2019 17:41:22 +0900 From: Won-Kyo Choe To: kernelnewbies@kernelnewbies.org Subject: How to handle page allocation when memory exceeds a local node Message-ID: <20190822084121.GA26988@swarm01.ajou.ac.kr> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org Suppose that there are two nodes and each node has 16GiB memory size. When a process needs pages from the kernel, I understand that __alloc_pages_nodemask() will do allocation for the process. In the function, I noticed that if there is no available page on a zone (or a node) while it loops for_next_zone_zonelist_nodemask() (a macro in get_page_from_freelist()), the kernel would try to reclaim reclaimable page from the zone. This loops will continue until the kernel gets a free page. This means that the kernel would try to find a page from the remote node if there is no free page in the local node. My question is that when the kernel starts to allocate a page from the remote node due to no enough memory in the local node, does the kernel always check there is a reclaimable page from the local node? In other words, does the kernel always start to find a page from the very first entry (which would be the local node and the first zone) in the loop? In my perspective, if the kernel starts to allocate in the remote node, I think the scheduler should move the process to the remote node and it will allocate a page in the remote node at first in the loop (in the process view, the node would be the local now since it is moved). Would the scheduler do that? Regards, WK Choe _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies