Date: Mon, 18 Mar 2013 08:26:17 -0500 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: freebsd-current@freebsd.org Subject: Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots Message-ID: <514715F9.2080506@freebsd.org> In-Reply-To: <CAOgwaMthTbj5k%2B03WSNGK7wm0aTufd1czQotM1wF0mAVnU7HLQ@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?514715F9.2080506>