On Mon, Nov 13, 2017 at 11:25:21AM -0800, Mike Kravetz wrote:
> On 11/13/2017 11:10 AM, Johannes Weiner wrote:
> > On Mon, Nov 13, 2017 at 06:45:01PM +, Roman Gushchin wrote:
> >> Or, at least, some total counter, e.g. how much memory is consumed
> >> by hugetlb pages?
> >
> > I'm not a big
On Mon, Nov 13, 2017 at 11:25:21AM -0800, Mike Kravetz wrote:
> On 11/13/2017 11:10 AM, Johannes Weiner wrote:
> > On Mon, Nov 13, 2017 at 06:45:01PM +, Roman Gushchin wrote:
> >> Or, at least, some total counter, e.g. how much memory is consumed
> >> by hugetlb pages?
> >
> > I'm not a big
On Mon 13-11-17 16:33:05, Roman Gushchin wrote:
[...]
> IMO, /proc/meminfo should give a user a high-level overview of memory usage
> in the system, without a need to look into other places. Of course, we always
> have some amount of unaccounted memory, but it shouldn't be measured in Gb,
> as in
On Mon 13-11-17 16:33:05, Roman Gushchin wrote:
[...]
> IMO, /proc/meminfo should give a user a high-level overview of memory usage
> in the system, without a need to look into other places. Of course, we always
> have some amount of unaccounted memory, but it shouldn't be measured in Gb,
> as in
On 11/13/2017 11:10 AM, Johannes Weiner wrote:
> Maybe a simple summary counter for everything set aside by the hugetlb
> subsystem - default and non-default page sizes, whether they're used
> or only reserved etc.?
Yeah, one line is a lot more sane than 5 lines times all the extra
sizes. It'll
On 11/13/2017 11:10 AM, Johannes Weiner wrote:
> Maybe a simple summary counter for everything set aside by the hugetlb
> subsystem - default and non-default page sizes, whether they're used
> or only reserved etc.?
Yeah, one line is a lot more sane than 5 lines times all the extra
sizes. It'll
On 11/13/2017 11:10 AM, Johannes Weiner wrote:
> On Mon, Nov 13, 2017 at 06:45:01PM +, Roman Gushchin wrote:
>> Or, at least, some total counter, e.g. how much memory is consumed
>> by hugetlb pages?
>
> I'm not a big fan of the verbose breakdown for every huge page size.
> As others have
On 11/13/2017 11:10 AM, Johannes Weiner wrote:
> On Mon, Nov 13, 2017 at 06:45:01PM +, Roman Gushchin wrote:
>> Or, at least, some total counter, e.g. how much memory is consumed
>> by hugetlb pages?
>
> I'm not a big fan of the verbose breakdown for every huge page size.
> As others have
On Mon, Nov 13, 2017 at 06:45:01PM +, Roman Gushchin wrote:
> Or, at least, some total counter, e.g. how much memory is consumed
> by hugetlb pages?
I'm not a big fan of the verbose breakdown for every huge page size.
As others have pointed out such detail exists elswhere.
But I do think we
On Mon, Nov 13, 2017 at 06:45:01PM +, Roman Gushchin wrote:
> Or, at least, some total counter, e.g. how much memory is consumed
> by hugetlb pages?
I'm not a big fan of the verbose breakdown for every huge page size.
As others have pointed out such detail exists elswhere.
But I do think we
On Mon, Nov 13, 2017 at 10:30:10AM -0800, Mike Kravetz wrote:
> On 11/13/2017 10:17 AM, Dave Hansen wrote:
> > On 11/13/2017 10:11 AM, Roman Gushchin wrote:
> >> On Mon, Nov 13, 2017 at 09:06:32AM -0800, Dave Hansen wrote:
> >>> On 11/13/2017 08:03 AM, Roman Gushchin wrote:
> To solve this
On Mon, Nov 13, 2017 at 10:30:10AM -0800, Mike Kravetz wrote:
> On 11/13/2017 10:17 AM, Dave Hansen wrote:
> > On 11/13/2017 10:11 AM, Roman Gushchin wrote:
> >> On Mon, Nov 13, 2017 at 09:06:32AM -0800, Dave Hansen wrote:
> >>> On 11/13/2017 08:03 AM, Roman Gushchin wrote:
> To solve this
On 11/13/2017 10:17 AM, Dave Hansen wrote:
> On 11/13/2017 10:11 AM, Roman Gushchin wrote:
>> On Mon, Nov 13, 2017 at 09:06:32AM -0800, Dave Hansen wrote:
>>> On 11/13/2017 08:03 AM, Roman Gushchin wrote:
To solve this problem, let's display stats for all hugepage sizes.
To provide the
On 11/13/2017 10:17 AM, Dave Hansen wrote:
> On 11/13/2017 10:11 AM, Roman Gushchin wrote:
>> On Mon, Nov 13, 2017 at 09:06:32AM -0800, Dave Hansen wrote:
>>> On 11/13/2017 08:03 AM, Roman Gushchin wrote:
To solve this problem, let's display stats for all hugepage sizes.
To provide the
On 11/13/2017 10:11 AM, Roman Gushchin wrote:
> On Mon, Nov 13, 2017 at 09:06:32AM -0800, Dave Hansen wrote:
>> On 11/13/2017 08:03 AM, Roman Gushchin wrote:
>>> To solve this problem, let's display stats for all hugepage sizes.
>>> To provide the backward compatibility let's save the existing
On 11/13/2017 10:11 AM, Roman Gushchin wrote:
> On Mon, Nov 13, 2017 at 09:06:32AM -0800, Dave Hansen wrote:
>> On 11/13/2017 08:03 AM, Roman Gushchin wrote:
>>> To solve this problem, let's display stats for all hugepage sizes.
>>> To provide the backward compatibility let's save the existing
On Mon, Nov 13, 2017 at 09:06:32AM -0800, Dave Hansen wrote:
> On 11/13/2017 08:03 AM, Roman Gushchin wrote:
> > To solve this problem, let's display stats for all hugepage sizes.
> > To provide the backward compatibility let's save the existing format
> > for the default size, and add a prefix
On Mon, Nov 13, 2017 at 09:06:32AM -0800, Dave Hansen wrote:
> On 11/13/2017 08:03 AM, Roman Gushchin wrote:
> > To solve this problem, let's display stats for all hugepage sizes.
> > To provide the backward compatibility let's save the existing format
> > for the default size, and add a prefix
On 11/13/2017 08:03 AM, Roman Gushchin wrote:
> To solve this problem, let's display stats for all hugepage sizes.
> To provide the backward compatibility let's save the existing format
> for the default size, and add a prefix (e.g. 1G_) for non-default sizes.
Is there something keeping you from
On 11/13/2017 08:03 AM, Roman Gushchin wrote:
> To solve this problem, let's display stats for all hugepage sizes.
> To provide the backward compatibility let's save the existing format
> for the default size, and add a prefix (e.g. 1G_) for non-default sizes.
Is there something keeping you from
On Mon, Nov 13, 2017 at 05:11:02PM +0100, Michal Hocko wrote:
> On Mon 13-11-17 16:03:02, Roman Gushchin wrote:
> > Currently we display some hugepage statistics (total, free, etc)
> > in /proc/meminfo, but only for default hugepage size (e.g. 2Mb).
> >
> > If hugepages of different sizes are
On Mon, Nov 13, 2017 at 05:11:02PM +0100, Michal Hocko wrote:
> On Mon 13-11-17 16:03:02, Roman Gushchin wrote:
> > Currently we display some hugepage statistics (total, free, etc)
> > in /proc/meminfo, but only for default hugepage size (e.g. 2Mb).
> >
> > If hugepages of different sizes are
On Mon 13-11-17 16:03:02, Roman Gushchin wrote:
> Currently we display some hugepage statistics (total, free, etc)
> in /proc/meminfo, but only for default hugepage size (e.g. 2Mb).
>
> If hugepages of different sizes are used (like 2Mb and 1Gb on x86-64),
> /proc/meminfo output can be confusing,
On Mon 13-11-17 16:03:02, Roman Gushchin wrote:
> Currently we display some hugepage statistics (total, free, etc)
> in /proc/meminfo, but only for default hugepage size (e.g. 2Mb).
>
> If hugepages of different sizes are used (like 2Mb and 1Gb on x86-64),
> /proc/meminfo output can be confusing,
Currently we display some hugepage statistics (total, free, etc)
in /proc/meminfo, but only for default hugepage size (e.g. 2Mb).
If hugepages of different sizes are used (like 2Mb and 1Gb on x86-64),
/proc/meminfo output can be confusing, as non-default sized hugepages
are not reflected at all,
Currently we display some hugepage statistics (total, free, etc)
in /proc/meminfo, but only for default hugepage size (e.g. 2Mb).
If hugepages of different sizes are used (like 2Mb and 1Gb on x86-64),
/proc/meminfo output can be confusing, as non-default sized hugepages
are not reflected at all,
26 matches
Mail list logo
