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] [day] [month] [year] [list]
Date:	Mon, 22 Jan 2007 17:58:00 +0100
From:	"Kevin D. Kissell" <kevink@...s.com>
To:	"Jan Engelhardt" <jengelh@...ux01.gwdg.de>,
	"Ralf Baechle" <ralf@...ux-mips.org>
Cc:	"sathesh babu" <sathesh_edara2003@...oo.co.in>,
	<linux-mips@...ux-mips.org>, <linux-kernel@...r.kernel.org>
Subject: Re: Running Linux on FPGA

> On Jan 21 2007 00:14, Ralf Baechle wrote:
> >On Sat, Jan 20, 2007 at 11:42:37PM +0000, sathesh babu wrote:
> >
> >>   I am trying to run Linux-2.6.18.2 ( with preemption enable)
> >>   kernel on FPGA board which has MIPS24KE processor runs at 12
> >>   MHZ. Programmed the timer to give interrupt at every 10msec. I
> >>   am seeing some inconsistence behavior during boot up processor.
> >>   Some times it stops after "NET: Registered protocol family 17"
> >>   and "VFS: Mounted root (jffs2 filesystem).". Could some give
> >>   some pointers why the behavior is random. Is it OK to program
> >>   the timer to 10 msec? or should it be more.
> >
> >The overhead of timer interrupts at this low clockrate is
> >significant so I recommend to minimize the timer interrupt rate as
> >far as possible. This is really a tradeoff between latency and
> >overhead and matters much less on hardcores which run at hundreds of
> >MHz.
> 
> Hm I've been running 2.6.13 on a 10/20 MHz (switchable) i386 @ 100 Hz
> before without any hangs during boot or operation.

Interrupt service overhead varies a bit between architectures, but your
observation isn't too surprising.  While the 1000Hz Linux 2.6 default
is just bad craziness for embedded cores and FPGA prototypes, I've
only seen 100Hz be truly unusable for sub-megahertz hardware simulators,
and then only when running virtual SMP kernels, where multiple virtual
"CPUs" on the same core all had to perform timer interrupt service
every clock interval, which multiplies the proportion of available cycles
consumed.  But even if the system boots and runs, it's pretty scary
to look at the proportion of time that a 20MHz core spends in interrupt
service with a HZ value of 100 or more.

So on one hand I agree with Ralf that on slow systems, especially
FPGA systems, one wants to keep the clock interrupt frequency
down to no more than 100Hz as a general rule (less than 100
wouldn't compile on 2.6.9 without some minor patches, which
took the minimum down to HZ=48, below which the various macros
that depend on HZ start generating divide-by-zero problems),
while on the other hand I agree with Jan that it's by no means certain
that Satesh's problem is really one of too many clock interrupts.

            Regards,

            Kevin K.

-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ