This reverts commit abcd9d0.
… built-in to DSP Manager
Change-Id: If04a8e99942dbe7e099e736dc87c2a49e1e778f9 Signed-off-by: Dmitry Shmidt <firstname.lastname@example.org>
…requency Instead of checking only the absolute value of CPU load_freq to increase frequency, we detect forthcoming CPU load rise and increase frequency earlier. Every sampling rate, we calculate the gradient of load_freq. If it is too steep we assume that the load most probably will go over up_threshold in next iteration(s) and we increase frequency immediately. New tuners are introduced: - early_demand: to enable this functionality (disabled by default). - grad_up_threshold: over this gradient of load we will increase frequency immediately. Signed-off-by: Stratos Karafotis <email@example.com>
Use an inline function to evaluate freq_target to avoid duplicate code. Also, define a macro for the default frequency step. Signed-off-by: Stratos Karafotis <firstname.lastname@example.org> Fix the logic in frequency decrease checking When we evaluate the CPU load for frequency decrease we have to compare the load against down_threshold. There is no need to subtract 10 points from down_threshold. Instead, we have to use the default down_threshold or user's selection unmodified. Signed-off-by: Stratos Karafotis <email@example.com> Fix sampling_down_factor functionality sampling_down_factor tunable is unused since commit 8e677ce (4 years ago). This patch restores the original functionality and documents the tunable. Signed-off-by: Stratos Karafotis <firstname.lastname@example.org>
Use an inline function to evaluate freq_target to avoid duplicate code. Also, define a macro for the default frequency step. Signed-off-by: Stratos Karafotis <email@example.com>
This reverts commit 829873f.
The netlink URELEASE notifier doesn't notify for sockets that have been used to receive multicast but it should be called for such sockets as well since they might _also_ be used for sending and not solely for receiving multicast. We will need that for nl80211 (generic netlink sockets) in the future. Signed-off-by: Johannes Berg <firstname.lastname@example.org> Cc: Patrick McHardy <email@example.com> Signed-off-by: David S. Miller <firstname.lastname@example.org>
This reverts commit 7fecdc4.
This reverts commit 4946ee0.
…ernor." This reverts commit 358fd3c.
We leak at least 32bits of kernel memory to user land in tc dump, because we dont init all fields (capab ?) of the dumped structure. Use C99 initializers so that holes and non explicit fields are zeroed. Signed-off-by: Eric Dumazet <email@example.com> Signed-off-by: David S. Miller <firstname.lastname@example.org>
…cc 4.6.0" This reverts commit f38fec2.
This reverts commit b8a6234.
…ed pipe" This reverts commit 05a2c40.
This reverts commit 3272949.
commit 64f371b upstream. The autofs packet size has had a very unfortunate size problem on x86: because the alignment of 'u64' differs in 32-bit and 64-bit modes, and because the packet data was not 8-byte aligned, the size of the autofsv5 packet structure differed between 32-bit and 64-bit modes despite looking otherwise identical (300 vs 304 bytes respectively). We first fixed that up by making the 64-bit compat mode know about this problem in commit a32744d4abae ("autofs: work around unhappy compat problem on x86-64"), and that made a 32-bit 'systemd' work happily on a 64-bit kernel because everything then worked the same way as on a 32-bit kernel. But it turned out that 'automount' had actually known and worked around this problem in user space, so fixing the kernel to do the proper 32-bit compatibility handling actually *broke* 32-bit automount on a 64-bit kernel, because it knew that the packet sizes were wrong and expected those incorrect sizes. As a result, we ended up reverting that compatibility mode fix, and thus breaking systemd again, in commit fcbf94b9dedd. With both automount and systemd doing a single read() system call, and verifying that they get *exactly* the size they expect but using different sizes, it seemed that fixing one of them inevitably seemed to break the other. At one point, a patch I seriously considered applying from Michael Tokarev did a "strcmp()" to see if it was automount that was doing the operation. Ugly, ugly. However, a prettier solution exists now thanks to the packetized pipe mode. By marking the communication pipe as being packetized (by simply setting the O_DIRECT flag), we can always just write the bigger packet size, and if user-space does a smaller read, it will just get that partial end result and the extra alignment padding will simply be thrown away. This makes both automount and systemd happy, since they now get the size they asked for, and the kernel side of autofs simply no longer needs to care - it could pad out the packet arbitrarily. Of course, if there is some *other* user of autofs (please, please, please tell me it ain't so - and we haven't heard of any) that tries to read the packets with multiple writes, that other user will now be broken - the whole point of the packetized mode is that one system call gets exactly one packet, and you cannot read a packet in pieces. Tested-by: Michael Tokarev <email@example.com> Cc: Alan Cox <firstname.lastname@example.org> Cc: David Miller <email@example.com> Cc: Ian Kent <firstname.lastname@example.org> Cc: Thomas Meyer <email@example.com> Signed-off-by: Linus Torvalds <firstname.lastname@example.org> Signed-off-by: Greg Kroah-Hartman <email@example.com>
commit 9883035 upstream. The actual internal pipe implementation is already really about individual packets (called "pipe buffers"), and this simply exposes that as a special packetized mode. When we are in the packetized mode (marked by O_DIRECT as suggested by Alan Cox), a write() on a pipe will not merge the new data with previous writes, so each write will get a pipe buffer of its own. The pipe buffer is then marked with the PIPE_BUF_FLAG_PACKET flag, which in turn will tell the reader side to break the read at that boundary (and throw away any partial packet contents that do not fit in the read buffer). End result: as long as you do writes less than PIPE_BUF in size (so that the pipe doesn't have to split them up), you can now treat the pipe as a packet interface, where each read() system call will read one packet at a time. You can just use a sufficiently big read buffer (PIPE_BUF is sufficient, since bigger than that doesn't guarantee atomicity anyway), and the return value of the read() will naturally give you the size of the packet. NOTE! We do not support zero-sized packets, and zero-sized reads and writes to a pipe continue to be no-ops. Also note that big packets will currently be split at write time, but that the size at which that happens is not really specified (except that it's bigger than PIPE_BUF). Currently that limit is the system page size, but we might want to explicitly support bigger packets some day. The main user for this is going to be the autofs packet interface, allowing us to stop having to care so deeply about exact packet sizes (which have had bugs with 32/64-bit compatibility modes). But user space can create packetized pipes with "pipe2(fd, O_DIRECT)", which will fail with an EINVAL on kernels that do not support this interface. Tested-by: Michael Tokarev <firstname.lastname@example.org> Cc: Alan Cox <email@example.com> Cc: David Miller <firstname.lastname@example.org> Cc: Ian Kent <email@example.com> Cc: Thomas Meyer <firstname.lastname@example.org> Signed-off-by: Linus Torvalds <email@example.com> Signed-off-by: Greg Kroah-Hartman <firstname.lastname@example.org>
* Useful so userspace tools can reconfigure. Change-Id: Ib423910b8b9ac791ebe81a75bf399f58272f64f2
This will let us use it on a nlmsghdr stored inside a netlink_callback. Signed-off-by: Nelson Elhage <email@example.com> Signed-off-by: David S. Miller <firstname.lastname@example.org>
It produces more false positives than useful warnings.
This reverts commit 7ec0fa3.
This reverts commit bbec504.
This reverts commit a60d736.