Date:	Tue, 2 Mar 2010 08:36:54 -0700
From:	"Rick L. Vinyard, Jr." <rvinyard@...nmsu.edu>
To:	"Jaya Kumar" <jayakumar.lkml@...il.com>
Cc:	linux-kernel@...r.kernel.org, npavel@...ner.com,
	tomi.valkeinen@...ia.com, tony@...mide.com,
	florianschandinat@....de, krzysztof.h1@...pl,
	akpm@...ux-foundation.org, linux-fbdev@...r.kernel.org,
	jkosina@...e.cz, bonbons@...ux-vserver.org
Subject: Re: [PATCH] Add sysfs support for fbdefio delay


Jaya Kumar wrote:
> On Tue, Mar 2, 2010 at 12:10 AM, Rick L. Vinyard, Jr.
> <rvinyard@...nmsu.edu> wrote:
>> Jaya Kumar wrote:
>>> Hi Rick,
>>>
>>> On Fri, Feb 26, 2010 at 6:15 AM, Rick L. Vinyard Jr.
>>> <rvinyard@...nmsu.edu> wrote:
>>>
>>>> +               Set the deferred I/O delay of the framebuffer in ms.
>>>> +               This value can be used to throttle deferred I/O
>>>> updates.
>>>
>>> Please help us understand how userspace should use the ability to set
>>> this delay.
>>
>> I think that there isn't one specific answer since, just like the
>> approach
>> to priority of processes there isn't one specific answer. The real
>> answer
>> is: it depends.
>
> Rick,
>
> Thanks for your reply.
>
>>
>> One of the factors I was concerned about was having two or more G13
>> devices on the same bus with other traffic. Each frame is sent as an
>> interrupt transfer out, and I was concerned that the framebuffer updates
>> might be detrimental to other traffic.
>>
>> I know that a pair of G13 devices running at 30 FPS would only consume
>> about 5% of the USB 1.1 bandwidth (~500 Mbit/s) for framebuffer
>> transfers
>> (sans headers and other control messages), but I was concerned that it
>> could introduce enough latency to make other devices laggy.
>
> You mentioned in your responses and above that you're concerned about
> saturating the USB bus and lagginess, and I think it is good to have
> those concerns. Defio delay may be an easy parameter to expose, and in
> at least a specific set of drivers, changing it would have a
> meaningful effect on bus utilization, but are you convinced that
> exposing it generally (remember your patch makes it apply to all fb
> drivers) to userspace is a right way or even a good way to address bus
> saturation concerns?
>
>> As a result of this translation, I was concerned with the driver
>> consuming
>> too much CPU time when doing multiple translations for multiple
>> devices...
>> or even one translation on a limited or saturated CPU at a high frame
>> rate.
>
> Being concerned about CPU utilization is a good thing. But say for
> example, your USB ethernet driver or USB audio driver is taking a lot
> of cpu time packetizing traffic, then would I be correct that your
> desire is to expose an inter-packetization driver specific sleep time
> controllable by userspace via sysfs for all ethernet, audio, etc
> drivers? (by driver specific, I mean the sysfs parameter would be
> presented by all drivers but the value would be specific to each one,
> which is the way your current patch would behave for all fb drivers).
>

I think the answer is yes, whether this were a fb, network, audio, etc. If
there is a clearly defined parameter at which resource utilization can be
adjusted in a standard way.

Although the value is specific to each one, the min/max parameters provide
the bounds and standardized units, allowing userspace to modify the delay
parameter in a standardized way.

I also tried to make it where the driver had to explicitly modify the
min/max parameters so that unless a driver sets min/max values the delay
parameter can be examined from userspace but not modified.

I agree that the motivation for throttling varies by device, and even as
in this case there could be different motivations for the same device (USB
bus bandwidth and/or CPU utilization).

I think that what also distinguishes the fbdefio case is the fact that
there is a single defined point at which resource utilization would be
throttled and that's the fb_deferred_io structure's deferred_io hook.

>> I think it would be an interesting possibility to develop a daemon that
>> watched traffic on buses with USB devices that could be throttled and
>> throttle them according to bus saturation.
>>
>> However, at this point I wasn't planning on going there. But, having the
>> ability to throttle would be a key point for developing such daemons.
>
> Just curious, do such sysfs throttling parameters exist for any other
> subsystems? If so, are userspace apps/services using them, and are
> they happy with it?

An example of something like this is the ACPI CPU thermal class. It
provides two parameters, cur_state and max_state. The minimum is presumed
to be 0.

In this case though, I think fbdefio needs to provide both a min and a max
as a driver may want to set the minimum refresh rate to be non-zero.

Another example would be the CPU frequency subsystem, and in particular
the userspace governor. There are similar sysfs attributes for obtaining
the current frequency, setting the frequency, and obtaining the min/max
frequencies.

In particular they used:
     scaling_cur_freq (ro)
     scaling_min_freq (ro)
     scaling_max_freq (ro)
     scaling_setspeed (wo)

I used a single read/write attribute for read/write on the delay instead
of the two parameter approach used for frequencies. I used:
     defio_delay     (rw)
     defio_delay_min (ro)
     defio_delay_max (ro)

But, it wouldn't be hard to use an analogous set like:
     defio_cur_delay (ro)
     defio_min_delay (ro)
     defio_max_delay (ro)
     defio_set_delay (wo)

-- 

Rick

--
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