[Openmp-dev] cpuinfo file reliance

[Itaru Kitayama via Openmp-dev]

I think on Linux, hardware info is supposed to
obtained through sysfs, in an architecture independent way. But as Jeff
says the consensus is that we don’t touch the code until bugs pop up,
that’s fine.

On Sat, Jul 4, 2020 at 7:57 Churbanov, Andrey <Andrey.Churbanov at intel.com>
wrote:

> The cpuinfo file topology method was designed to show the library machine
> topology without requiring it to investigate the topology itself.
>
> The file can be written manually, it should not necessarily be
> /proc/cpuinfo.  It can be /my_folder/my_cpuinfo_file for example, or
> c:\my_folder\my_cpuinfo_file.txt on Windows.
>
> Only requirement is to follow format that the library can recognize.  One
> can always write own file, e.g. basing on info provided by lscpu or any
> other tool.
>
>
>
> This method can work on any architecture that allows to bind a thread
> using an affinity mask.
>
>
>
> The goal was to allow to test affinity on machines where cpuid instruction
> cannot work, or cpuid has interface that the library cannot recognize, or
> to test binding on some future architecture using old system, or to avoid
> issuing cupid instruction by the library for some reason, etc.
>
>
>
> -- Andrey
>
>
>
> *From:* Openmp-dev <openmp-dev-bounces at lists.llvm.org> * On Behalf Of *Hal
> Finkel via Openmp-dev
> *Sent:* Saturday, July 4, 2020 12:18 AM
> *To:* Itaru Kitayama <itaru.kitayama at gmail.com>; Jeff Hammond <
> jeff.science at gmail.com>
> *Cc:* openmp-dev <openmp-dev at lists.llvm.org>
> *Subject:* Re: [Openmp-dev] cpuinfo file reliance
>
>
>
>
>
> On 7/3/20 3:42 PM, Itaru Kitayama via Openmp-dev wrote:
>
> Jeff,
>
> Linux supports other arches than X86, and the
>
> layout of cpuinfo is different across the architectures.
>
>
>
> In the runtime code if you take a look at already  there are ifdefs.
>
>
>
> Itaru.
>
>
>
> The alternative that you're proposing is to fork lscpu to read
> /proc/cpuinfo instead?
>
> We do understand that /proc/cpuinfo has architecture dependencies, and
> this is unfortunate in this context, but it is the interface that Linux
> provides. How does lscpu deal with those dependencies? Should our parser
> just be more robust?
>
>  -Hal
>
>
>
>
>
> On Fri, Jul 3, 2020 at 23:48 Jeff Hammond <jeff.science at gmail.com> wrote:
>
> I’m not sure lscpu program is any better and it’s not standard on Linux
> the way /proc/cpuinfo is.
>
> What is the specific problem you are seeing? Perhaps you can explain that
> before trying to design a solution.
>
> Jeff
>
> > On Jul 2, 2020, at 10:55 PM, Itaru Kitayama via Openmp-dev <
> openmp-dev at lists.llvm.org> wrote:
> >
> > Is there a plan to move away from arch dependent cpuinfo file to lscup
> > when creating an affinity map? It has clearly different a format on
> AArch64.
> > _______________________________________________
> > Openmp-dev mailing list
> > Openmp-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>
>
>
> _______________________________________________
>
> Openmp-dev mailing list
>
> Openmp-dev at lists.llvm.org
>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>
> --
>
> Hal Finkel
>
> Lead, Compiler Technology and Programming Languages
>
> Leadership Computing Facility
>
> Argonne National Laboratory
>
>
> --------------------------------------------------------------------
> Joint Stock Company Intel A/O
> Registered legal address: Krylatsky Hills Business Park,
> 17 Krylatskaya Str., Bldg 4, Moscow 121614,
> <https://www.google.com/maps/search/17+Krylatskaya+Str.,+Bldg+4,+Moscow+121614,++Russian+Federation?entry=gmail&source=g>
> Russian Federation
> <https://www.google.com/maps/search/17+Krylatskaya+Str.,+Bldg+4,+Moscow+121614,++Russian+Federation?entry=gmail&source=g>
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20200704/f2a8730f/attachment.html>