quoted

Hmm..
Your answer didn't match I wanted.

Then I don't get what you want.

I want to know the benefit of the patch for patch reviewing.

quoted

few additional questions.

- Why don't you change your application? It seems natural way than kernel change.

There is no way to change my application and achieve what I've described
in a multithreaded app.

Then, we don't recommend to use mlockall(). I don't hope to hear your conclusion,
it is not objectivization. I hope to hear why you reached such conclusion.

quoted

- Why do you want your virtual machine have mlockall? AFAIK, current majority
  virtual machine doesn't.

It is absolutely irrelevant for that patch, but just because you ask I
want to measure the cost of swapping out of a guest memory.

No. if you stop to use mlockall, the issue is vanished.

quoted

- If this feature added, average distro user can get any benefit?

?! Is this some kind of new measure? There are plenty of much more
invasive features that don't bring benefits to an average distro user.
This feature can bring benefit to embedded/RT developers.

I mean who get benifit?

quoted

I mean, many application developrs want to add their specific feature
into kernel. but if we allow it unlimitedly, major syscall become
the trushbox of pretty toy feature soon.

And if application developer wants to extend kernel in a way that it
will be possible to do something that was not possible before why is
this a bad thing? I would agree with you if for my problem was userspace
solution, but there is none. The mmap interface is asymmetric in regards
to mlock currently. There is MAP_LOCKED, but no MAP_UNLOCKED. Why
MAP_LOCKED is useful then?

Why? Because this is formal LKML reviewing process. I'm reviewing your
patch for YOU.

If there is no objective reason, I don't want to continue reviewing.