Re: [PATCH 2/3] mm: introduce fincore()

Re: [PATCH 2/3] mm: introduce fincore()

[Christoph Hellwig]

Please also provide a man page for the system call.

I'm also very unhappy about the crazy different interpretation of the
return value depending on flags, which probably becomes more obvious if
you try to document it.

That being said I think fincore is useful, but why not stick to the
same simple interface as mincore?

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] mm: introduce fincore()

[Naoya Horiguchi]

On Sun, Jun 01, 2014 at 11:42:26PM -0700, Christoph Hellwig wrote:
> Please also provide a man page for the system call.

Yes, I'll do it.

> I'm also very unhappy about the crazy different interpretation of the
> return value depending on flags, which probably becomes more obvious if
> you try to document it.

The meaning of the return value doesn't change due to flags, it's always
"the number of valid entries passed to userspace,"  not dependent on the
mode (unlike the size of data for example.)

The reason why I did this is skip hole mode, where fincore() could end scanning
before filling up the userspace buffer. So then the caller wants to know where
is the end point of valid data. I thought that the simplest way is to return
it as the return value. It's also possible to to let userspace know it by doing
like below:
- a userspace application zeroes the whole range of the buffer before calling
  fincore(FINCORE_SKIP_HOLE)
- after the fincore() returns, it finds the first hole entry then the index
  of the hole entry gives the number of valid entries.

Yes, we can do it without the return value, but it takes some costs so I
didn't like it.

> That being said I think fincore is useful, but why not stick to the
> same simple interface as mincore?

mincore() gives only 8-bit field for each page, so we can easily guess that
in the future we will face the need of more information to be passed and we
don't have enough room for it.

Another reason is that currently we have some interfaces to expose page status
information to userspace like /proc/kpageflags, /proc/kpagecount, and
/proc/pid/pagemap. People (including me) tried to add a new interface when they
need a new infomation, but this is not good direction in a long run (too many
/proc/kpage* interfaces). I think fincore() provides a unified way to do it.
One benefit of it is that we can get the data you want in a single call, no need
to call (for example) /proc/pid/pagemap and then /proc/kpageflags separately,
which results in less overhead.

Thanks,
Naoya Horiguchi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>