From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4CC566A2.2000702@domain.hid> Date: Mon, 25 Oct 2010 13:14:42 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4CC20AD2.4060501@domain.hid> <4CC44C02.4050003@domain.hid> <4CC5603E.1090707@domain.hid> In-Reply-To: <4CC5603E.1090707@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Slow hard drive access in xenomai List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix , Peter Pastor Cc: xenomai@xenomai.org Am 25.10.2010 12:47, Gilles Chanteperdrix wrote: > Eric Noulard wrote: >> 2010/10/24 Peter Pastor : >>> Hey Gilles, >>> I am in the process to configure the xenomai kernel as you suggested. >>> I found and disabled the options that you suggested (NUMA, SPARSEMEM, >>> SECCOMP, AUDITSYSCALL, KPROBES, FTRACE, SELINUX), However, I could not >>> disable SPARSEMEM. Searching for SPARSEMEM in the kernel configuration >>> simply says "Symbol: SPARSEMEM [=y]" and does not give me any further info. >>> Can you tell me how to disable it ? >> >> SPARSEMEM may be a dependence for other options. >> If you look into the mm/Kconfig file >> http://lxr.linux.no/#linux+v2.6.32/mm/Kconfig#L103 >> you may discover which options you have may need SPARSEMEM. >> >> For example the CONFIG_MEMORY_HOTPLUG depends on SPARSEMEM. >> >>> Also, I disabled NUMA even though the info states "For 64-bit this is >>> recommended if the system is Intel Core i7 (or later), AMD Opteron, or >>> EM64T" and my system is a 64bit, with 8 Intel Xeon cores. Hope that is ok... >> >> NUMA stands for Non Uniform Memory Access essentially it is for multiprocessor >> machine which have a memory layout which is not "symmetric" (aka Uniform) with >> respect to each processor. >> You have some "pictured" example of NUMA systems on the HWLOC project >> http://www.open-mpi.org/projects/hwloc/ >> http://www.open-mpi.org/projects/hwloc/doc/v1.0.2/#examples >> >> Now I really don't know if enabling NUMA handling is mandatory for NUMA systems >> I guess yuo could disable NUMA handling at kernel level but yuo may >> get performance >> weirdness because the kernel is not aware of the NUMA nature. >> >> This is pure guess, I let others give you a more "secure" answer to this. > > From what I understood NUMA means that you have several "nodes" with a > fast local memory and a slow remote memory. If you only have one CPU, > which accesses only one DRAM bank, you do not need NUMA. In any case, > the boot logs will tell you how many NUMA nodes are created. But since > Peter never sent a full boot log, I have no idea what the boot logs say. > NUMA should not cause such issues (we are running Xenomai on real NUMA), nor should it cause noticeable slowdowns when enabled but unused. Let's focus on the core issue, a potentially spurious IRQ: Peter, can you check if 2.6.35 shows the same symptoms (2.6.31 is unmaintained anyway)? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux