From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH RFC] eal: change default per socket memory allocation Date: Tue, 06 May 2014 17:18:52 +0200 Message-ID: <3138330.LfuR0euKkp@xps13> References: <1398867304-21171-1-git-send-email-david.marchand@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev-VfR2kkLFssw@public.gmane.org To: "Burakov, Anatoly" Return-path: In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 2014-05-06 10:05, Burakov, Anatoly: > David Marchand: > > Actually, if we don't care where memory is allocated, we can at least try > > to have the more common setup work properly (i.e. spread memory > > allocations based on used cores). > > I can see no usual setup where you > > want to use cores on a socket while having all memory on another socket > > but still expect performance to be good. > > So here is another approach for Didier's patch. > > We can try to spread memory on numa sockets, if this fails, then we > > default to previous behavior but leave a trace with a warning log "Could > > not spread memory on numa sockets". > > What do you think about this ? > > Sounds like an overcomplication to me. There could be cases where > performance doesn't matter, for example the -m switch could be used to run > various tests (unit tests, functional tests etc.). For anything > performance-related, the recommended option is to use --socket-mem, > especially if you have NICs on specific sockets. Presumably, when you're > setting up a coremask, you already know which sockets your cores are on, so > I don't see a problem with specifying which sockets you want memory from. Having --socket-mem option to explicitly configure NUMA is OK. Having -m option for simple configuration is OK. Making -m option working for most use cases would be really nice. So I don't understand why we shouldn't do this enhancement. I don't know if "overcomplication" is a good argument. Maybe we should wait the patch to discuss it. -- Thomas