From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F17B444106; Wed, 29 May 2024 23:51:41 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C6DBC402B0; Wed, 29 May 2024 23:51:41 +0200 (CEST) Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by mails.dpdk.org (Postfix) with ESMTP id 4F23F40273 for ; Wed, 29 May 2024 23:51:40 +0200 (CEST) Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-1f44b4404dfso2559365ad.0 for ; Wed, 29 May 2024 14:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1717019499; x=1717624299; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=HN1qtb7Ga7VMqri/4poBIMIDbXUcuU9qm5W4Y8XayTE=; b=rLhKPxX+hbZo0t0rIQWU9OveJ2EhqOT0bSJTa+2FZdxdD8Xw54ud/d6X+7Djm4zUVK pB5Rt37CCDL1HllSIUn8mNoebgJIcrBPrZrKnPsVLhSVNlAHbk3rYGbrzThXMuSLfv/e 6wQljW9viG7NCg9BO9Kha65G2EoqjDa38wCrVMt3YpDzk0pyGRyDp/MqGJoinA/pkWqI Tb0PnYaTgPl/snJQXvtCX0W2xzoAle1+dnxqW/nuKqUxuF/p8ksVVlkTBpnAMhnMRtji agCvVEJTXtJBr/0rc1t+QBjwRcKXEjLBJFbyzjWmY/4yR57L4UyppsaxWdYpbK8FZ6DJ /ZnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717019499; x=1717624299; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HN1qtb7Ga7VMqri/4poBIMIDbXUcuU9qm5W4Y8XayTE=; b=Jl/3arushuLRCNtzJZ22CbVRr44Yl5FbUqzhrRmMC0sSsjQyZhBmOHsWalEAroI/zh UVXRFmEgljjdnxnz318Hh6wLWdbEzTR4NoIhoC7siXSSJiDH7kvje01fEV/hcWGf8tq5 gc+++yaIymvOU35OZ3khIYPk+hwkGYMwrkguMQNSGA2L9VT+RPSNNk2LQEYlbkKQe6vS gqp0juw8z/1Tn9Zh2Uj95P1YlEcrcYAAJ/UrO1NTga1voiahAVeNu3MRUm+ySc2DbSid vY1EFve/Az/I57hhLtajZn0VXoNMLJD88qlv0WI3qrqHJaz/Ve59td7PbgmNRLzYnffs B9NQ== X-Forwarded-Encrypted: i=1; AJvYcCUXRIL2JLy6Ayb78ibyFmzcWFHdZzWquVpb6Ycm0y1+SyvfJn5QUMkZkEOT2sk9HuJaN7SPMCcj3+rwx2s= X-Gm-Message-State: AOJu0YztcDzb8QGF3NKOSmbmekBBaq19lfS4W0qFdpP/HNnywJVCbGeG eW/8wjTInL9VsubFLcsisoVDzbIHULzTAGr0tqnJofcL1jGzYDrqh+uXpOqkTTOB/Alh2SmOexA m X-Google-Smtp-Source: AGHT+IFFu0JKqqje5VHIkfbEoRGtX86M0TfI8QZ/IJi1pJmj5ME/+qIzWQNZ0NlsLtJJolhU11B5jg== X-Received: by 2002:a17:902:d509:b0:1f4:a6a5:4271 with SMTP id d9443c01a7336-1f6199365e6mr3008685ad.55.1717019499321; Wed, 29 May 2024 14:51:39 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1f488f665a9sm70859875ad.205.2024.05.29.14.51.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 May 2024 14:51:39 -0700 (PDT) Date: Wed, 29 May 2024 14:51:37 -0700 From: Stephen Hemminger To: Fengnan Chang Cc: anatoly.burakov@intel.com, dev@dpdk.org, xuemingl@mellanox.com Subject: Re: [PATCH] eal: speed up dpdk init time Message-ID: <20240529145137.58dabd74@hermes.local> In-Reply-To: <20240528061259.29528-1-changfengnan@bytedance.com> References: <20240528061259.29528-1-changfengnan@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, 28 May 2024 14:12:59 +0800 Fengnan Chang wrote: > If we have a lot of huge pages in system, the memory init will > cost long time in legacy-mem mode. For example, we have 120G memory > in unit of 2MB hugepage, the env init will cost 43s. Almost half > of time spent on find_numasocket, since the address in > /proc/self/numa_maps is orderd, we can sort hugepg_tbl by orig_va > first and then just read numa_maps line by line is enough to find > socket. In my test, spent time reduced to 19s. > > Signed-off-by: Fengnan Chang > --- Good speed up, but you could do much better if the code only read /proc/self/numa_maps once and constructed an internal table. Could use a hash or tree to store the relatively small table.