Date: Mon, 18 Mar 2013 07:56:45 -0700 From: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-current@freebsd.org, Nathan Whitehorn <nwhitehorn@freebsd.org> Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots Message-ID: <CAOgwaMvsoa=TWebXq14VzvNrNQZuLg9Kr63-tmq8ZZ42%2B79mOQ@mail.gmail.com> In-Reply-To: <D09D34E518E94C3CAC98DAE7486CE62A@multiplay.co.uk> References: <CAOgwaMss0cB9bFqCkjzukb-=9FqgLN9vthL5QdQsk-6Lknk5VQ@mail.gmail.com> <CAFHbX1LcCGoWy%2BHzp8T7z4noFZAMK1-sCuWpO_Z_ybhnoMMY5A@mail.gmail.com> <CAOgwaMtTmx4LhEdrg3WNjZA-uyTRSN913RBWrrqMia4GZhP_zA@mail.gmail.com> <CAFHbX1KkD7fWP%2BKZNrSjzCStUM_Smjw7GdKDTo=DjjMoe5ttGA@mail.gmail.com> <35878.1363607691@critter.freebsd.dk> <CAOgwaMthTbj5k%2B03WSNGK7wm0aTufd1czQotM1wF0mAVnU7HLQ@mail.gmail.com> <514715F9.2080506@freebsd.org> <D09D34E518E94C3CAC98DAE7486CE62A@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 18, 2013 at 7:47 AM, Steven Hartland <killing@multiplay.co.uk>wrote: > > ----- Original Message ----- From: "Nathan Whitehorn" < > nwhitehorn@freebsd.org> > To: <freebsd-current@freebsd.org> > Sent: Monday, March 18, 2013 1:26 PM > Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in > slots > > > On 03/18/13 07:18, Mehmet Erol Sanliturk wrote: >> >>> On Mon, Mar 18, 2013 at 4:54 AM, Poul-Henning Kamp <phk@phk.freebsd.dk >>> >wrote: >>> >>> In message <CAFHbX1KkD7fWP+KZNrSjzCStUM_**Smjw7GdKDTo= >>>> DjjMoe5ttGA@mail.gmail.com>, Tom Evans writes: >>>> >>>> You say this, have you actually measured/checked. sysutils/dmidecode >>>>> will interrogate your BIOS and tell us what it thinks is installed in >>>>> each RAM socket. It is not uncommon for RAM to say one thing on the >>>>> outside, and report something completely different to the BIOS. >>>>> >>>> >>>> I can only second Tom's call for a proper scientific approach to >>>> debugging this issue, rather than just assume that it is the >>>> operating systems fault. >>>> >>>> -- >>>> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >>>> phk@FreeBSD.ORG | TCP/IP since RFC 956 >>>> FreeBSD committer | BSD since 4.3-tahoe >>>> Never attribute to malice what can adequately be explained by >>>> incompetence. >>>> >>>> >>> >>> I am a graduate of Operations Research and Statistics option of a >>> Mathematics department . >>> All of your considerations are considered . It is so much apparent that , >>> the cause is FreeBSD . >>> >>> In my previous year message and in its subsequent messages , there are >>> sufficiently detailed information . >>> >>> >>> This message is caused from the following fact : >>> >>> In previous year case , KDE used was a cause , but FluxBox was working >>> fast >>> . >>> Now , I have installed 10.0 current . It does not have KDE in packages . >>> I >>> have installed FluxBox . >>> It is not a few second slow : Many minutes to start Firefox , and >>> activate >>> a menu of it ! >>> >>> What is the point of measuring milliseconds when the difference is around >>> many minutes ? >>> >>> PC-BSD installation ( it is a graphical installation after starting X ) >>> is >>> taking many hours to reach 20 percent completion . >>> The same is for GhostBSD : Start it at night , at the next morning , it >>> is >>> likely that it is not finished yet . >>> >>> >>> Then : WQhat will be measured ? >>> >>> Linux installations are around 30 minutes . >>> Starting/Opening menus are instantenous : I do no have chronometer , but >>> everything is within a second . >>> >>> >>> Thank you very much . >>> >> >> The problem is that "slow" doesn't mean anything. An incomplete list of >> things it might be related to: >> 1. Something to do with the way KDE is built (options, system compiler) >> 2. A disk I/O issue >> 3. A memory speed issue >> 4. Some other process using CPU that isn't running on Linux >> 5. A scheduler issue triggered by some property of the machine >> >> Doing some of these smaller tests will help pin down which of these are >> causing the problem. Without that, there's no possibility to even start >> debugging. Even just running top and seeing whether you are spinning in >> a user thread, in the kernel, or waiting while the slow things are >> happening would be extremely helpful. >> > > Surely you can eliminate all of those and confirm / deny the original > diagnosis by simply installing balanced memory in the machine and checking > to see if the problem goes away? > > Could this be an NUMA related issue? > > Regards > Steve > > Please see links in my previous mails . All of these are worked in detail . This is Intel DG965WH main board and I do not know much about NUMA , but with respect to Wikipedia Non-Uniform_Memory_Access page , it seems that there is no NUMA structure in this main board . Thank you very much . Mehmet Erol Sanliturk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOgwaMvsoa=TWebXq14VzvNrNQZuLg9Kr63-tmq8ZZ42%2B79mOQ>