On 03-08-20, 22:31, Dongdong Yang wrote: > From: Dongdong Yang <yangdongdong@xxxxxxxxxx> > > This patch provides USF(User Sensitive Feedback factor) auxiliary > cpufreq governor to support high level layer sysfs inodes setting > for utils adjustment purpose from the identified scenario on portable > equipment. Because the power consumption and UI response are more cared > for by portable equipment users. And the "screen off" status stands for > no request from the user, however, the kernel is still expected to > notify the user in time on modem, network or powerkey events occur. USF > provides "sched_usf_non_ux_r" sysfs inode to cut down the utils from > user space tasks according to high level scenario. In addition, it > usually hints more cpufreq demand that the preemptive counts of the > tasks on the cpu burst and over the user expecting completed time such > as the ratio sysctl_sched_latency to sysctl_sched_min_granularity on > "screen on" status, which more likely with more UI. The sysfs inodes > "sched_usf_up_l0_r" and "sched_usf_down_r" have been provided to adjust > the utils according to high level identified scenario to alloc the > cpufreq in time. > > Changes in v3 > - Move usf.c to kernel/sched. > - Remove trace_printk and debugfs. > - Add document draft. > - Update comments. > > Changes in v2 > - Add adjust_task_pred_set switch. > - Move adjust_task_pred_demand declaration into sched.h > - Update comments. Sending updated patchset for this isn't going to help you my friend. You need people (maintainers) to agree on the idea here first. The patch can be beautified later if required once the idea is agreed upon. I saw Peter already gave his NAK to it during V1. You need to discuss with people here to see why they don't like it first and as Greg said earlier, this should not go to staging at all if it ever makes it mainline. The more versions you send now (without proper discussions first), the harder it will be for this stuff to get merged upstream. -- viresh _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
