I want to add that you usually have no incentive to flush a memtable to disk. Flushing memtables does not add durability: Anyway, every write to a memtable also goes to a "commit log" on disk - and these logs are replayed in case of crash so that no writes are lost. The longer you can hold off flushing memtables to disk, and consolidate different updates to the same row in memory, the less work you'll need to do later on compacting these small sstables together. Of course, there is a tradeoff between flushing memtables to disk soon and leaving a lot of memory free for caching less-recent-but-more-useful data, and flushing memtables after they have grown very big (and potentially consolidating multiple changes to the same row) and leaving little memory for cached but not-recently-written data. This is the tradeoff that the controller that Dor mentioned does.
If you really want to flush memtables *now*, you have a "nodetool flush" command to do that, but in most cases you have no reason to use it.