Re: FreeBSD is very slow when Memory chip sizes are imbalanced in slots

On Mon, Mar 18, 2013 at 7:47 AM, Steven Hartland <killing_at_multiplay.co.uk>wrote:

>
> ----- Original Message ----- From: "Nathan Whitehorn" <
> nwhitehorn_at_freebsd.org>
> To: <freebsd-current_at_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_at_phk.freebsd.dk
>>> >wrote:
>>>
>>>  In message <CAFHbX1KkD7fWP+KZNrSjzCStUM_**Smjw7GdKDTo=
>>>> DjjMoe5ttGA_at_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_at_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