Date: Fri, 1 Sep 2006 03:41:12 -0500 (CDT) From: Scott Bennett <bennett@cs.niu.edu> To: backyard <backyard1454-bsd@yahoo.com> Cc: Questions <freebsd-questions@freebsd.org>, "Chad Leigh -- Shire.Net LLC" <chad@shire.net> Subject: Re: shared cache -- Re: SMP detection Message-ID: <200609010841.k818fCrc012644@mp.cs.niu.edu>
next in thread | raw e-mail | index | archive | help
On Thu, 31 Aug 2006 08:18:57 -0700 (PDT)
backyard <backyard1454-bsd@yahoo.com> wrote:
>--- "Chad Leigh -- Shire.Net LLC" <chad@shire.net>
>wrote:
>
>>
>> On Aug 30, 2006, at 12:12 PM, backyard wrote:
>>
>> > with HT disabling in FreeBSD is more for the
>> security
>> > issues about a potential exploit whereby one
>> process
>> > in one pipe can access the priveledged information
>> of
>> > a process in another pipe because the two cores
>> share
>> > one processor cache and thus one cache table. To
>> my
>> > knowledge this hasn't been exploited yet.
>>
>>
>> How is this any different than say an Intel Core Duo
>> or Core 2 Duo?
>> I believe they have a shared cache as well for each
>> (real) processor
>> core.
I'm not sure about the Core Duo, but I think it
has two separate, fixed-sized caches. The Core 2 Duo
supposedly keeps a total of 4 MB of L2 cache, but
dynamically manages how much is currently used by each
core, still keeping what they use separate (i.e., each
core can only access what is allocated to it).
>>
>> Chad
>>
>> ---
>> Chad Leigh -- Shire.Net LLC
>> Your Web App and Email hosting provider
>> chad at shire.net
>>
>>
>
>I would say there is no difference if what you say is
>true. A Multi-Core chip is only true SMP if the two
>cores share no resources internally and thus are
>capable of running process separate from each other
>entirely. independantly and with their own internal
>caches. The process shouldn't have to wait on a lock
>to access it's cache, which I would have to assume
>occurs on these HT machines; which is probably why
>they have degraded performance. The cache should only
>be shared if a process explicity copies its content to
>the other cores cache. If should not be possible for
>both Cores to see the same internal cache. To my
Thus far, Intel's dual-cored processors do not have
HT enabled, though the circuitry may well be present.
Intel has said publicly that they may make HT available
again at some point, so that each core would have two
logical processors. If Intel does that, then presumably
the FreeBSD kernel would need a third level of processor
relationships in addition to the distinction between
processors in the same group (i.e., logical processors
in a particular real processor) versus processors in
different groups (i.e., logical processors in different
real processors).
>knowledge the AMDx2 follow this model with independant
>cores only sharing a common die. This ensures the
>context and priveledge of one running process cannot
>be compromised by a non-priveldeged process waiting on
>say a login attempt to root, and then grabbing the
>password from the common cache before the privelidged
>process can clean up.
Many people have panned HT, but HT does make it
possible to keep more components of a real processor
(e.g., DAT, TLB, FPU, address and data lines to the off-
chip world, etc.) in active use more of the time. This
is an issue that is separate from the issues involving
multiple real processors on one die. It is, of course,
too bad that Intel's design allows the logical processors
to cross-access their cache spaces, but I doubt that that
particular weakness has hurt anyone much.
A greater problem for some installations is the
accounting problem caused by the fact that a logical
processor waiting for a hardware lock set by another
logical processor in the same core appears to have 100%
CPU utilization during the lockout. In other words,
100% utilization of both logical processors is equivalent
to something on the order of 110% - 140% utilization of
a single logical processor that has no competition from
another logical processor. So which thread is getting
overcharged? The software cannot determine the answer.
And what institutional accounting policy should be in
effect to handle billing for CPU time in an HT-enabled
environment, given this indeterminacy?
>
>I don't think this flaw has been exploited yet, but
>the boys at OpenBSD found it (from memory, pretty sure
>it was one of them) and it has spread through the BSD
>community as it has potentially dire consequences.
>
>Personally I'm done with Intel so I don't think I'll
>ever have this issue. Afterall they're still the
>reason my computer boots up with 640k of RAM... I also
>think AMD has come from being a clone to being on top
>of the market, but this is my personal opinion. The
>fact Core Duos are only 32-bit means Intel is still
>only concerned with shortend gains on the Windows
>market, not long term migration to 64-bit PCs like
That's not quite entirely true. According to the
Intel web site, some models of Core chips don't list
EM64T as a supported feature, but some of the *do*.
The Core Solo and Core Duo series do not show EM64T as
a feature, but the entire Mobile Core 2 Duo series, the
Core 2 Extreme X6800, and the entire Core 2 Duo Desktop
series do list EM64T as a supported feature.
>everyone else... And banking on Microsoft has never
>been a solid idea; its too bad banks use Windows;
>there's a security nightmare, but a topic in and of
>itself...
Indeed. (Ugh!)
>
>-brian
>
Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet: bennett at cs.niu.edu *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
* -- Gov. John Hancock, New York Journal, 28 January 1790 *
**********************************************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200609010841.k818fCrc012644>