The "real memory" column is resident set size, a completely useless metric for the problem at hand because of many reasons. One reason is that much of the physical pages can be shared, indeed most of them usually are, on my system a chrome process has a 120MB RSS, but after closer inspection 110MB is shared, and after even closer inspection 90MB is shared with non-chrome processes. Closing the process with top RSS usage might do very little for decreasing memory pressure. Another reason is that physical memory usage is very misleading, if the system is swapping, a process has less resident physical pages than the virtual pages it uses, that's the reason the system is swapping in the first place! A process can thrash memory and have a relatively small RSS.
You also simply assume what the problem is without actually testing for it. You need to look why the system spends time in kernel mode, maybe it's not swapping, most likely is not swapping in this particular case, it's more likely to be the random I/O caused on-demand paging of memory mapped things or something more subtle, like copy-on-write pages being written to. It also could be a million other things.
Even if the problem is caused by memory pressure, memory pressure is a remarkably generic term, the VM system has many components and different components are affected by different workloads. A simple metric like RSS can't tell much.
Yes, Activity Monitor is very blunt tool.