[lkml]   [2000]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Inconsistencies in 3dNOW handling
> - CONFIG_MK6 is described as "K6/K6-II/K6-III", and CONFIG_MK7 as
> "Athlon/K7". Of these two, only the latter defines
> CONFIG_X86_USE_3DNOW, although K6-II and K6-III do provide 3DNOW
> instructions.

The Athlon has an extended version of 3DNOW, which the kernel uses as of
test11-pre2. The entire 3DNOW option has nothing to do with userspace;
unlike the Screaming Sindy Extensions, 3DNOW requires no (extra) kernel

The 3DNOW option is about the kernel using extended instructions for
internal functions such as zero_page() and copy_page().
This is no advantage on K6 processors, but on Athlon processors (well, most
of them anyway) it is a gain of more than a factor 2 for these functions.
The test11pre2 code will also not run on a K6-II/III, but this valid due to the
fact that this new code is > 2x faster than the old code, and the old code
was no win on the K6-II/III anyway.

> * On older X86 processors its not a win to use MMX here it seems.
> * Maybe the K6-III ?
> Gasp. Would it or not in the end be useful to add a CONFIG_MK6II
> option that would enable 3DNOW ?

Won't work. (see previous comment).

> - In all places where 3DNOW is tested (strings-486.h, page.h), only
> MMX-specific funcs are used (_mmx_memcpy mostly, mmx_{clear,copy}_page)
> page.h says:

> So do they use MMX or 3Dnow after all ? They are distinct processor
> features, aren't they ?

Some of the "MMX" instructions are part of "3Dnow" according to AMD
publications. This is especially true for the "prefetch" instructions which
have a different memnonic/opcode on Intel CPU's.

> - BTW, what does this 512 stand for ? Especially as it's used in
> several places, a #define would seem nice at first glance.

The 512 is a rough estimate of the minimum size of the copy that makes it
worth saving and restoring the extra processor-state for using mmx.

> - drivers/md/xor.c says:
> certain CPU features like MMX can only be detected runtime
> I'm not sure how much this relates to the above, but I'd say a MMX
> config option could be used for this ? Or a common detection routine
> that other drivers could use ?

The way it is done now, even a generic i386 compiled kernel (think
distributions) will use the fast MMX raid code. For the copy_page and
friends this extra test is probably too much overhead. (the < 512 test is
inlined and often constant...)

Arjan van de Ven

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:45    [W:0.033 / U:1.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site