It tells me you are using RAID 5, or you manually put like files on the same disk controller. If the latter is true, spread out your like files so they are not on the same controllers. For example, when Oracle goes to update all copies of your control file it is fastest to have only one control file for all disks under controller A, and another control file for all disks under controller B. If you have only 1 controller, like a home computer, then there is nothing to be done.
Suppose you're using RAID 5 such that the control (or redo logs, or other files) are spread out evenly across all available disks. for example, for your first file the first block goes on disk 1, the second block on disk2, and so on. for your second file a similar thing occurs, and so on for each file. When Oracle tries to update all copies of the control file it it writing to all disks for all files. that's a lot of I/O bottlenecks.
with all of that said, look at your spreport output again. take the wait time and divide by 100, because the default is centiseconds. then divide that number by the number of waits. If your final number is something like 0.0001 then waits are not an issue, regardless of how big the spreport numbers looked at first.
Spreading out your redo logs is a different story. You can (and might need to) have several such files under the same disk controller. The book Oracle 24x7 shows many example of how to deal with this issue.