linux-kernel - Re: Disabling DMA with ICH10?

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]

Message-ID: <20090928234025.6dc4e3f7@lxorguk.ukuu.org.uk>
Date:	Mon, 28 Sep 2009 23:40:25 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	unlisted-recipients:; (no To-header on input)
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Disabling DMA with ICH10?

> 1. Is there a way to completely disable DMA usage system-wide?

No

> 2. My system uses an ICH10 chipset, the harddrive is connected to the
> Intel SATA controller. Is there a way to disable DMA and switch back to
> PIO? I tried compiling with libata support and without SCSI support, but
> the kernel is unable to mount root (no matter if /dev/sda1
> or /dev/hda1), then.

If you disable DMA you will make your performance and latency worse not
better as the PIO transfers will stall the bus and thus the processor.

> If disabling DMA is impossible for some reason for one or both drivers,
> is it at least possible to reduce the burst sizes so the bus gets free
> for a short time during which I could access it from my real time kernel
> module?

You want the disk controller in AHCI mode to minimise CPU stalls and
then any burst size configuration and the like is down to the PCI
configuration. On some systems where memory or bus bandwidth is an issue
then forcing the disk to run at a lower speed can help, at least for
PATA. What effect it will have on SATA I am less sure.

If you really are that latency sensitive then the more normal approach
would be to lock one core for real time use, load the critical code into
that core CPU cache and run from cache. If you are utterly pushing the
limit you might even do crazy stuff like use on thread on the core to
execute RT stuff and the other to issue any I/O accesses that might stall.

And then on many systems things like BIOS SMI glue will still clobber you
8(

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