[Linux-ia64] CONFIG_IA64_L1_CACHE_SHIFT

[Linux-ia64] CONFIG_IA64_L1_CACHE_SHIFT

[Jes Sorensen]

Hi

Anyone who can explain why there is a 

define_int CONFIG_IA64_L1_CACHE_SHIFT 6

in the config file? We already have SMP_CACHE_BYTES and L1_CACHE bytes
for all architectures, it doesn't make a whole lot of sense to me ot
invent yet another alignment rule.

Jes

Re: [Linux-ia64] CONFIG_IA64_L1_CACHE_SHIFT

[David Mosberger]

>>>>> On 01 Mar 2001 20:29:28 +0100, Jes Sorensen <jes@linuxcare.com> said:

  Jes> Hi Anyone who can explain why there is a

  Jes> define_int CONFIG_IA64_L1_CACHE_SHIFT 6

  Jes> in the config file? We already have SMP_CACHE_BYTES and
  Jes> L1_CACHE bytes for all architectures, it doesn't make a whole
  Jes> lot of sense to me ot invent yet another alignment rule.

$ fgrep CONFIG_IA64_L1 include/asm-ia64/cache.h 
#define L1_CACHE_SHIFT          CONFIG_IA64_L1_CACHE_SHIFT

	--david

Re: [Linux-ia64] CONFIG_IA64_L1_CACHE_SHIFT

[Jes Sorensen]

>>>>> "David" = David Mosberger <davidm@hpl.hp.com> writes:

>>>>> On 01 Mar 2001 20:29:28 +0100, Jes Sorensen <jes@linuxcare.com> said:
Jes> in the config file? We already have SMP_CACHE_BYTES and L1_CACHE
Jes> bytes for all architectures, it doesn't make a whole lot of sense
Jes> to me ot invent yet another alignment rule.

David> $ fgrep CONFIG_IA64_L1 include/asm-ia64/cache.h #define
David> L1_CACHE_SHIFT CONFIG_IA64_L1_CACHE_SHIFT

Hmmm ok

It just seemed weird to have it in the config.in file. Btw. shouldn't
the acpi code use SMP_CACHE_BYTES for alignment? It doesn't buy you a
whole lot to align on L1 cache boundaries if you're trying to be SMP
aware - or is it rather a DMA vs CPU alignment issue?

Jes

RE: [Linux-ia64] CONFIG_IA64_L1_CACHE_SHIFT

[Mallick, Asit K]

Also this is configurable to take care of future processors that may have
higher cache line sizes.

Thanks,
Asit


> -----Original Message-----
> From: David Mosberger [mailto:davidm@hpl.hp.com]
> Sent: Thursday, March 01, 2001 2:35 PM
> To: Jes Sorensen
> Cc: linux-ia64@linuxia64.org
> Subject: Re: [Linux-ia64] CONFIG_IA64_L1_CACHE_SHIFT
> 
> 
> >>>>> On 01 Mar 2001 20:29:28 +0100, Jes Sorensen 
> <jes@linuxcare.com> said:
> 
>   Jes> Hi Anyone who can explain why there is a
> 
>   Jes> define_int CONFIG_IA64_L1_CACHE_SHIFT 6
> 
>   Jes> in the config file? We already have SMP_CACHE_BYTES and
>   Jes> L1_CACHE bytes for all architectures, it doesn't make a whole
>   Jes> lot of sense to me ot invent yet another alignment rule.
> 
> $ fgrep CONFIG_IA64_L1 include/asm-ia64/cache.h 
> #define L1_CACHE_SHIFT          CONFIG_IA64_L1_CACHE_SHIFT
> 
> 	--david
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
> 

Re: [Linux-ia64] CONFIG_IA64_L1_CACHE_SHIFT

[David Mosberger]

>>>>> On 02 Mar 2001 00:18:48 +0100, Jes Sorensen <jes@linuxcare.com> said:

>>>>> "David" = David Mosberger <davidm@hpl.hp.com> writes:
>>>>> On 01 Mar 2001 20:29:28 +0100, Jes Sorensen <jes@linuxcare.com> said:
  Jes> in the config file? We already have SMP_CACHE_BYTES and
  Jes> L1_CACHE bytes for all architectures, it doesn't make a whole
  Jes> lot of sense to me ot invent yet another alignment rule.

  David> $ fgrep CONFIG_IA64_L1 include/asm-ia64/cache.h #define
  David> L1_CACHE_SHIFT CONFIG_IA64_L1_CACHE_SHIFT

  Jes> Hmmm ok

  Jes> It just seemed weird to have it in the config.in
  Jes> file.

Why?  The cache line size is not defined by the architecture (only the
_minimum_ size is architected at 32 bytes), so it may well vary with
future chips.  Also, on some platforms it's beneficial to align to a
bigger size (e.g., SN1), even if the L1 cache line size is the same.

  Jes> Btw. shouldn't the acpi code use SMP_CACHE_BYTES for alignment?
  Jes> It doesn't buy you a whole lot to align on L1 cache boundaries
  Jes> if you're trying to be SMP aware - or is it rather a DMA vs CPU
  Jes> alignment issue?

I don't know.  Not to hurt any feelings, but the ACPI code is a
monstrous piece of software that strikes me as being very poorly
integrated into the Linux kernel.  It seems to redo everything on its
own and does so often more poorly than if it were to use the existing
facilities.  Case in point: it defines its own unaligned access macros
in acmacros.h even though such a facility already is provided in
<asm/unaligned.h>.  Of course, the stuff provided in <asm/unaligned.h>
does the Right Thing, unlike the macros defined in acmacros.h.  Sigh.

My suspicion is that the acpi code is also needlessly complex.  The
ACPI spec obviously doesn't help things (must be the worst spec ever
written), but I think the whole situation is not unlike USB: a poor
spec is likely to lead to a poor implementation, but that doesn't mean
it can't be implemented cleanly.  The question is of course whether
someone cares enough to attempt to either clean up the existing
implementation or re-implement the entire thing from scratch.

	--david

RE: [Linux-ia64] CONFIG_IA64_L1_CACHE_SHIFT

[Grover, Andrew]

Hi David,

Please see the detailed response below. (Sorry for the length, but you raise
a lot of issues.)

-- Andy

>   Jes> Btw. shouldn't the acpi code use SMP_CACHE_BYTES for alignment?
>   Jes> It doesn't buy you a whole lot to align on L1 cache boundaries
>   Jes> if you're trying to be SMP aware - or is it rather a DMA vs CPU
>   Jes> alignment issue?
> 
> I don't know.  Not to hurt any feelings, but the ACPI code is a
> monstrous piece of software that strikes me as being very poorly
> integrated into the Linux kernel.  It seems to redo everything on its
> own and does so often more poorly than if it were to use the existing
> facilities.  Case in point: it defines its own unaligned access macros
> in acmacros.h even though such a facility already is provided in
> <asm/unaligned.h>.  Of course, the stuff provided in <asm/unaligned.h>
> does the Right Thing, unlike the macros defined in acmacros.h.  Sigh.
> 
> My suspicion is that the acpi code is also needlessly complex.  The
> ACPI spec obviously doesn't help things (must be the worst spec ever
> written), but I think the whole situation is not unlike USB: a poor
> spec is likely to lead to a poor implementation, but that doesn't mean
> it can't be implemented cleanly.  The question is of course whether
> someone cares enough to attempt to either clean up the existing
> implementation or re-implement the entire thing from scratch.

It would probably help for you to understand where this code comes from. The
ACPI code we contribute is a "Linuxized" version of Intel's ACPI component
architecture (ACPI CA) source. ACPI CA is integrated into many operating
systems and supports 16-bit, 32-bit, and 64-bit environments. As such,
certain modularizations must be done to make sure it can be easily ported to
all of the environments. For example, the clib is not linked to the kernel
so we need to provide the functions that we need. This is why we define our
own alignment macros. While we maintain the ACPI CA code, we have to keep it
this way so that all ACPI CA users can benefit from development and bug
fixes. This includes the FreeBSD folks who are forging ahead of Linux, and
many of the IA-64 Unix OS vendors.

In the future, when we have achieved certain functional power management
milestones under Linux and a significant number of developers have come to
understand the complexity of the ACPI subsystem, it makes sense that the
code be optimized explicitly for the target OS environment. We expect that
this will happen over time for each OS vendor - the OS vendor should start
maintaining and advancing their OS specific ACPI implementation. In the mean
time, we need to keep it like it is. Take a look at the Unix-based or
Window-based dev environment ACPI CA code at:
http://developer.intel.com/technology/iapc/acpi/downloads.htm and see if
that looks any better to you. This code is run through a source formatting
program (linuxizer) before we contribute it. Linus inspected and approved
the output for use in the Linux kernel.

Although the code is complex, we do not feel that it is "needlessly
complex".  ACPI encompasses a great deal - far more than just simple power
management.  The ACPI work is a major effort. If it wasn't, we would not
have had to do it - meaning no one other than MS and one other OS vendor
attempted it (the FreeBSD folks). We've been working on it for between 5-7
man-years at this point and there is still significant effort to come --
both in changes to the Linux driver model and dynamic device enumeration and
configuration enhancements that need to be undertaken before we can really
get Linux-based systems to survive a transition from wake to sleep to wake
again. It is complex because its problem domains are complex and varied.

It's hard code to jump in and understand because one needs such a large
background to understand all the ACPI-isms. I hope this helps you and others
understand more about why the code is like it is. It should probably also be
moved out of the drivers directory into a core os component directory of its
own because it's not really a driver.  In the future, changes will be
necessary to Linux32 in like manner that they have been made to Linux64 to
support the initialization of systems without an APM/MPS/PnPBIOS legacy.
When the OS finally can enumerate and load drivers for motherboard-based
devices using the ACPI namespace, things will need to look much different.
In the mean time, we teeter on the edge of providing power management with
the ACPI support and static legacy based support of non-ACPI devices.

That said, if you find something wrong or lacking in the code (such as the
alignment macros) - please inform us so that we can fix the problem - a
patch would be even better. We care enough to do a correct implementation,
but we have a lot of work on our plate right now.

Regards -- Andy

RE: [Linux-ia64] CONFIG_IA64_L1_CACHE_SHIFT

[David Mosberger]

>>>>> On Fri, 2 Mar 2001 15:30:18 -0800 , "Grover, Andrew" <andrew.grover@intel.com> said:

  Andrew> In the future, when we have achieved certain functional
  Andrew> power management milestones under Linux and a significant
  Andrew> number of developers have come to understand the complexity
  Andrew> of the ACPI subsystem, it makes sense that the code be
  Andrew> optimized explicitly for the target OS environment. We
  Andrew> expect that this will happen over time for each OS vendor -
  Andrew> the OS vendor should start maintaining and advancing their
  Andrew> OS specific ACPI implementation.

Yes, I agree with this.  My mail wasn't so much meant to critize the
existing code (like you say: it does what it is designed for...) but
to encourage others to think about developing a leaner, more tightly
integrated version for Linux.  I think it would be a nice challenge to
see what could be done in this area, but it would definitely be a
non-trivial project.

	--david