The impact with external storage is bigger, of course. When you read from a file, you have 1 round-trip: send the request to the SAN and get the data back. With atime, you have another round-trip to update the atime on the storage system. While both round-trips could be combined on the initial read, this would not work when the data is in the file system cache, in which case, you just have the update for atime.

What do you mean with "big machine"? The atime stuff is not CPU intensive - it causes I/O. So you could avoid this additional I/O by deactivating it. Whether this helps in your situation depends on the workload you process. For example, if you have lots of table scans and a not-so-good BPHR, you have more disk I/O, which would be less expensive with atime. On the other side, the Linux kernel developers try to reduce the impact of atime handling by batching-up such updates. (At least, that's what I read the other day.)