The merit of data cache cleaning

Hello everyone, my 1st question to the ARM community; please excuse my ignorance.  Fairly recently, I shared OCM (on-chip-memory) on Xilinx Zynq processor (which is dual ARM Cortex A9).  To pass message between the 2 cores, I followed the Xilinx example and turned off L1 and L2 cache for this OCM.  But at first, I actually tried to keep L1 turned on the OCM by relying on DMB to do the job, which did NOT work.  I realized that I did NOT understand cache after all.  Scanning the web, this is what I gathered:

• Invalidation and cleaning are different.  Part of the CPU startup code INVALIDATES caches and enables them.
• If I still wanted cacheing on the OCM, I have to clean the cache after writing the message content into the OCM so that the cacheline will migrate to the OCM memory.  Then, I *believe* that through the magic of cache coherency, what I wrote on CPU1 will migrate to the CPU0's cache (if that part of the memory is in the cacheline).  Maybe more precisely, that cacheline is marked dirty and then on the next memory access on CPU0 will pull in the changed content.

But beyond the basics, I have a few questions:

1. Does one have to clean the WHOLE L1 data cache (all 32 KB of it) AND the L2 cache, or is there a way to clean ONLY the cacheline that is affected by my most recent write?  I could not think of a way to find out where the cacheline I just touched may be.
2. IF there is no way to identify the cacheline of interest, and I am forced to clean L1 and L2 (if L2 is turned on) cache, wouldn't there be a severe performance penalty in cache clening?  Yet, people talk about flushing the cache all the time (especially in device driver context).  Does this mean that the cache cleaning performance penalty is negligible?

Thank you very much for considering my questions.  Perhaps these are such basic questions, and I should have learned this in school, but I could not find a clear discussion online.