Atom processor inclusion

Atom processor inclusion

[Kelly Bowa]

Hi Ingo,

Any ideas if the Atom CPU patch mentioned here
http://groups.google.ca/group/fa.linux.kernel/browse_thread/thread/26d61febdf354055/a0b4c902e41b5fbf?hl=en&ie=UTF-8&q=config_mcore2+atom
has been submitted/considered for mainline inclusion. AFAIK GCC 4.5
*should* contain the architecture specific code.

Re: Atom processor inclusion

[Ingo Molnar]

* Kelly Bowa <kelly.bowa@gmail.com> wrote:

> Hi Ingo,
> 
> Any ideas if the Atom CPU patch mentioned here
> http://groups.google.ca/group/fa.linux.kernel/browse_thread/thread/26d61febdf354055/a0b4c902e41b5fbf?hl=en&ie=UTF-8&q=config_mcore2+atom
> has been submitted/considered for mainline inclusion. AFAIK GCC 4.5
> *should* contain the architecture specific code.

Yep, it looked acceptable - Tobias, do you have any 
updates / latest version of that patch?

	Ingo

Re: Atom processor inclusion

[Tobias Doerffel]

[-- Attachment #1: Type: Text/Plain, Size: 419 bytes --]

Hi,

Am Donnerstag, 20. August 2009 12:50:29 schrieb Ingo Molnar:
> Yep, it looked acceptable - Tobias, do you have any
> updates / latest version of that patch?
No - it's still the improved version I posted at the end of May [1]. The 
question is what to do with MODULE_PROC_FAMILY (CORE2 or ATOM) and the mtune-
fallback (generic, i686, ...)?

Regards,

Tobias


[1] http://lkml.org/lkml/2009/5/29/374

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Atom processor inclusion

[H. Peter Anvin]

On 08/20/2009 05:33 AM, Tobias Doerffel wrote:
> Hi,
> 
> Am Donnerstag, 20. August 2009 12:50:29 schrieb Ingo Molnar:
>> Yep, it looked acceptable - Tobias, do you have any
>> updates / latest version of that patch?
> No - it's still the improved version I posted at the end of May [1]. The 
> question is what to do with MODULE_PROC_FAMILY (CORE2 or ATOM) and the mtune-
> fallback (generic, i686, ...)?
> 

Without benchmarks, we're flying blind on that one... although in
general, "generic" is probably best in the sense that it doesn't imply
that anything else has been done to it.

As far as MODULE_PROC_FAMILY it really comes down to if we use movbe or
not, which I don't believe your patch does.  On the other hand, I really
think it's extremely unlikely that anyone will use modules compiled for
a different CPU, so I'm personally fine with changing that string.

That whole mechanism is kind of broken, anyway.

	-hpa

Re: Atom processor inclusion

[Arjan van de Ven]

H. Peter Anvin wrote:
> On 08/20/2009 05:33 AM, Tobias Doerffel wrote:
>> Hi,
>>
>> Am Donnerstag, 20. August 2009 12:50:29 schrieb Ingo Molnar:
>>> Yep, it looked acceptable - Tobias, do you have any
>>> updates / latest version of that patch?
>> No - it's still the improved version I posted at the end of May [1]. The 
>> question is what to do with MODULE_PROC_FAMILY (CORE2 or ATOM) and the mtune-
>> fallback (generic, i686, ...)?
>>
> 
> Without benchmarks, we're flying blind on that one... although in
> general, "generic" is probably best in the sense that it doesn't imply
> that anything else has been done to it.
> 
> As far as MODULE_PROC_FAMILY it really comes down to if we use movbe or
> not, which I don't believe your patch does.  On the other hand, I really
> think it's extremely unlikely that anyone will use modules compiled for
> a different CPU, so I'm personally fine with changing that string.
> 
> That whole mechanism is kind of broken, anyway.
> 

personally, I would prefer it if we did a simple hash of the WHOLE cflags,
and put that into the module version string.
Anything else is just a weak, and useless, substitute for that.

Using different CFLAGS in any shape or form should disqualify the module
as "incompatible".. and a simple hash is sufficient for that.....

Re: Atom processor inclusion

[Ingo Molnar]

* Arjan van de Ven <arjan@linux.intel.com> wrote:

> H. Peter Anvin wrote:
>> On 08/20/2009 05:33 AM, Tobias Doerffel wrote:
>>> Hi,
>>>
>>> Am Donnerstag, 20. August 2009 12:50:29 schrieb Ingo Molnar:
>>>> Yep, it looked acceptable - Tobias, do you have any
>>>> updates / latest version of that patch?
>>> No - it's still the improved version I posted at the end of May [1]. 
>>> The question is what to do with MODULE_PROC_FAMILY (CORE2 or ATOM) 
>>> and the mtune-
>>> fallback (generic, i686, ...)?
>>>
>>
>> Without benchmarks, we're flying blind on that one... although in
>> general, "generic" is probably best in the sense that it doesn't imply
>> that anything else has been done to it.
>>
>> As far as MODULE_PROC_FAMILY it really comes down to if we use movbe or
>> not, which I don't believe your patch does.  On the other hand, I really
>> think it's extremely unlikely that anyone will use modules compiled for
>> a different CPU, so I'm personally fine with changing that string.
>>
>> That whole mechanism is kind of broken, anyway.
>>
>
> personally, I would prefer it if we did a simple hash of the WHOLE 
> cflags, and put that into the module version string. Anything else 
> is just a weak, and useless, substitute for that.
>
> Using different CFLAGS in any shape or form should disqualify the 
> module as "incompatible".. and a simple hash is sufficient for 
> that.....

makes sense.

	Ingo

Re: Atom processor inclusion

[H. Peter Anvin]

On 08/21/2009 12:38 PM, Ingo Molnar wrote:
> 
> makes sense.
> 

OK, but I think that's a separate project.  For now, I'll put the patch
as-is into tip:x86/cpu.

	-hpa

Re: Atom processor inclusion

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> wrote:

> On 08/21/2009 12:38 PM, Ingo Molnar wrote:
> > 
> > makes sense.
> > 
> 
> OK, but I think that's a separate project.  For now, I'll put the 
> patch as-is into tip:x86/cpu.

I agree with the review feedback given - we can make merge of that 
dependent on measurements, etc.

	Ingo