linux-kernel - Re: high system cpu load during intense disk i/o

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:	Tue, 7 Aug 2007 01:37:08 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Dimitrios Apostolou <jimis@....net>
Cc:	Rafał Bilski <rafalbilski@...eria.pl>,
	linux-kernel@...r.kernel.org
Subject: Re: high system cpu load during intense disk i/o

> > acpi_pm_read is capable of disappearing into  SMM traps which will make
> > it look very slow.
> 
> what is an SMM trap? I googled a bit but didn't get it...

One of the less documented bits of the PC architecture. It is possible to
arrange that the CPU jumps into a special mode when triggered by some
specific external event. Originally this was used for stuff like APM and
power management but some laptops use it for stuff like faking the
keyboard interface and the Geode uses it for tons of stuff.

As SMM mode is basically invisible to the OS what oprofile and friends
see isn't what really occurs. So you see

	pci write -> some address

you don't then see

	SMM
	CPU saves processor state
	Lots of code runs (eg i2c polling the battery)
	code executes RSM

	Back to the OS

and the next visible profile point. This can make an I/O operation look
really slow even if it isn't the I/O which is slow.

> the reason I'm talking about a "software driver limit" is because I am 
> sure about some facts:
> - The disks can reach very high speeds (60 MB/s on other systems with udma5)

Is UDMA5 being selected firstly ?

> So what is left? Probably only the corresponding kernel module.

Unlikely to be the disk driver as that really hasn't changed tuning for a
very long time. I/O scheduler interactions are however very possible.
-
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/