Messages in this thread | | | Date | Thu, 19 Jul 2007 16:15:03 +0200 | From | Zoltan Menyhart <> | Subject | Re: [BUGFIX]{PATCH] flush icache on ia64 take2 |
| |
KAMEZAWA Hiroyuki wrote:
> But is it too costly that flushing icache page only if a page is newly > installed into the system (PG_arch1) && it is mapped as executable ?
Well it was a bit long time ago, I measured on a Tiger box with CPUs of 1.3 GHz:
Flushing a page of 64 Kbytes, with modified data in D-cache (it's slower that not having modified data in the D-cache):
13.1 ... 14.7 usec.
You may have quicker machines, but having more CPUs or a NUMA architecture can slow it down considerably: - more CPUs have to agree that that's the moment to carry out a flush - NUMA adds delay
We may have, say 1 Gbyte / sec local i/o activity (using some RAIDs). Assume a few % of this 1 Gbyte is the program execution, or program swap in. It gives some hundreds of new exec pages / sec => some msec-s can be lost each sec.
I can agree that it should not be a big deal :-)
> I don't want to leak this (stupid) corner case to the file system layer. > Hmm...can't we do clever flushing (like your idea) in VM layer ?
As the VM layer is designed to be independent of the page read in stuff...
Thanks,
Zoltan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |