I'm not sure what "kernel processes" you are talking about. There is such a thing as kernel threads aka. kernel daemons (and do not confuse this with "threads" generally, which exist in userspace); these have names like
kthreadd and have other special characteristics by which they can be identified (read the link) but they are unlikely to have anything to do with what you are doing.
top does show these by default.
htop doesn't, but that can be toggled with shift-k (see the htop man page WRT kernel threads).
Kernel threads do not at all represent the totality of what the kernel is doing, most of which is in service to specific userland processes. WRT your example of waiting for disk access, in so far as this time is active processor time, it is reported as part of the time used by the process doing the deed. However, waiting on disk access is not necessarily time spent using the processor. This is time that involves neither kernel nor user space activities so it is not reportable as an activity (because it isn't an activity of the processor), although it can be measured on a clock (the same way a network request-response cycle can be timed on a clock, although it mostly does not involve any kind of activity by the local computer).
Specific I/O bottlenecks are found by inference this way (timing the round trip). I suspect you have it backward when you say, "clearly the system isn't coping"; in fact the system is mostly idle because there is an I/O bottleneck.
You can more generally infer significant IO/hardware related issues if the load average is high while the CPU is relatively idle. Top and htop both report load average and overall cpu usage at the top. A high load average is more than 1.0; if you notice that consistently while the CPU usage is less than 100%, it indicates a lot of waiting on hardware is going on. This could be the hardware itself malfunctioning or the driver which controls it. Diagnosing what hardware exactly is then a matter of stopping and starting whatever processes; eg, if you are doing something with a video camera and writing the data to disk, try doing the same thing but throwing the data away instead (eg, to
/dev/null). If the problem persists, it's the camera. If not, it is disk access.
If the load average is less than one and the cpu isn't maxed out, the system simply is not under load, meaning whatever envelope you think you are pushing, you actually aren't.