linux-kernel - Re: [PATCH] x86: set Pentium M as PAE capable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 2 Mar 2014 16:42:32 -0500
From:	Gene Heskett <gheskett@...v.com>
To:	Dave Jones <davej@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: set Pentium M as PAE capable

On Sunday 02 March 2014, Dave Jones wrote:
>On Sun, Mar 02, 2014 at 09:56:19PM +0100, Andreas Mohr wrote:
> > (BTW, would it be possible to transform Linux's PAE support into
> > boot-config or even fully runtime-detectable boot switching to
> > (non-)PAE, similar to or exceeding what XP offers with its static
> > boot-time flag?
> > Last time I checked PAE support config defines were spread over ~ 40
> > kernel source files though :-((()
>
>It would be a considerable amount of work to make it a runtime thing.
>Ten years ago, maybe it would be worth the effort perhaps, but I'd
>suggest just letting 32-bit slowly die instead of doing dramatic
>overhauls that will no doubt introduce a bunch of regressions in code
>that's been notoriously awful to debug issues in during the past.
>
>	Dave

There is a fly in that soup Dave, and that is the speed in a truly real 
time required environment.  IRQ latencies once the 32 bit scene have been 
left behind, either by PAE or a full 64 bit build are not at all well 
defined, and are of sufficient magnitudes in terms of the timing jitter, as 
to nearly destroy our ability to use software step generation to control 
our machine tools.  A motor being stepped every 200 microseconds (thats 
actually slow) will lose 50% of its available torque if the timing jitter 
in the step issuance is 10% of the period.

We routinely expect 2 to 3 u-s jitters on an Atom board running a 32 bit, 
RTAI enhanced build of what is by now a 5 year old kernel.  This is 
extremely board sensitive, and that same kernel running on this 4 core 
phenom, cannot stay inside of 40 u-s.  A case of more horsepower not being 
a good deal at all.

OTOH, we (LinuxCNC) are a very small user group. I just want to make you 
aware that we exist. We do retrofits mostly, because our software can make 
the part faster, but I would estimate there are 5 to 10k machines out there 
in the major manufacturing scene running our software, and that they 
include some of the heaviest hitters in the auto making business.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/