[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140623201503.GA4551@amd.pavel.ucw.cz>
Date: Mon, 23 Jun 2014 22:15:03 +0200
From: Pavel Machek <pavel@....cz>
To: Ilia Mirkin <imirkin@...m.mit.edu>
Cc: Greg KH <greg@...ah.com>,
kernel list <linux-kernel@...r.kernel.org>,
Ben Skeggs <bskeggs@...hat.com>,
Alexandre Courbot <acourbot@...dia.com>,
David Airlie <airlied@...ux.ie>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>
Subject: Re: unparseable, undocumented /sys/class/drm/.../pstate
Hi!
> >> >> > I guess better interface would be something like
> >> >> >
> >> >> > pstate/07/core_clock_min
> >> >> > core_clock_max
> >> >> > memory_clock_min
> >> >> > memory_clock_max
> >> >> >
> >> >> > and then pstate/active containing just the number of active state?
> >
> >> Could we just say that the format of this file is one-per-line of
> >>
> >> level: information-for-the-user
> >
> > But it is not.
>
> But it is...
>
> > Management tools will want to parse it, sooner or
> > later. What is wrong with solution described above?
>
> It is complex and annoying to the people that will actually use it.
grep -r . pstate/ is actually not that bad...
And yes, some kind of utility to select right performance level would
be nice in future... Or maybe not. Perhaps in not so distant future
kernel will use right performance level for given load...?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists