Re: [v7 5/5] mm, oom: cgroup v2 mount option to disable cgroup-aware OOM killer
On Fri, 8 Sep 2017, Christopher Lameter wrote: > Ok. Certainly there were scalability issues (lots of them) and the sysctl > may have helped there if set globally. But the ability to kill the > allocating tasks was primarily used in cpusets for constrained allocation. > I remember discussing it with him and he had some data with pretty extreme numbers for how long the tasklist iteration was taking. Regardless, I agree it's not pertinent to the discussion if anybody is actively using the sysctl, just fun to try to remember the discussions from 10 years ago. The problem I'm having with the removal, though, is that the kernel source actually uses it itself in tools/testing/fault-injection/failcmd.sh. That, to me, suggests there are people outside the kernel source that are also probably use it. We use it as part of our unit testing, although we could convert away from it. These are things that can probably be worked around, but I'm struggling to see the whole benefit of it. It's only defined, there's generic sysctl handling, and there's a single conditional in the oom killer. I wouldn't risk the potential userspace breakage. > The issue of scaling is irrelevant in the context of deciding what to do > about the sysctl. You can address the issue differently if it still > exists. The systems with super high NUMA nodes (hundreds to a > thousand) have somehow fallen out of fashion a bit. So I doubt that this > is still an issue. And no one of the old stakeholders is speaking up. > > What is the current approach for an OOM occuring in a cpuset or cgroup > with a restricted numa node set? > It's always been shaky, we simply exclude potential kill victims based on whether or not they share mempolicy nodes or cpuset mems with the allocating process. Of course, this could result in no memory freeing because a potential victim being allowed to allocate on a particular node right now doesn't mean killing it will free memory on that node. It's just more probable in practice. Nobody has complained about that methodology, but we do have internal code that simply kills current for mempolicy ooms. That is because we have priority based oom killing much like this patchset implements and then extends it even further to processes. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/15] Improve DVB documentation and reduce its gap
On 04.09.2017 13:29, Mauro Carvalho Chehab wrote: > Em Mon, 4 Sep 2017 02:55:15 +0200 > Soeren Moch escreveu: > >> Hi Mauro, >> >> On 01.09.2017 11:32, Mauro Carvalho Chehab wrote: >>> Em Fri, 1 Sep 2017 10:40:28 +0200 >>> Honza Petrouš escreveu: >>> 2017-09-01 1:46 GMT+02:00 Mauro Carvalho Chehab : > The DVB documentation was negligected for a long time, with > resulted on several gaps between the API description and its > documentation. > > I'm doing a new reading at the documentation. As result of it, > this series: > > - improves the introductory chapter, making it more generic; > - Do some adjustments at the frontend API, using kernel-doc > when possible. > - Remove unused APIs at DVB demux. I suspect that the drivers > implementing such APIs were either never merged upstream, > or the API itself were never used or was deprecated a long > time ago. In any case, it doesn't make any sense to carry > on APIs that aren't properly documented, nor are used on the > upstream Kernel. > > With this patch series, the gap between documentation and > code is solved for 3 DVB APIs: > > - Frontend API; > - Demux API; > - Net API. > > There is still a gap at the CA API that I'll try to address when I > have some time[1]. > > [1] There's a gap also on the legacy audio, video and OSD APIs, > but, as those are used only by a single very old deprecated > hardware (av7110), it is probably not worth the efforts. > >> av7110 cards may be old, but there are still users of these cards. >> For instance I'm watching TV received and decoded with such card in this >> moment. >> So what do you mean with "deprecated hardware"? > Nobody is telling otherwise. What I mean by "deprecated" is that it is > not a product that you could got to a shop and buy a new one. Its > production stopped a long time ago. > I agree that av7110 is very very old piece of hw (but it is already in my hall of fame because of its Skystar 1 incarnation as first implementation of DVB in Linux) and it is sad that we still don't have at least one driver for any SoC with embedded DVB devices. >>> Yeah, av7110 made history. Please notice that this series doesn't >>> remove any API that it is used by it. All it removes are the APIs >>> that there's no Kernel driver using. >>> >>> Carry on APIs without client is usually a very bad idea, as nobody >>> could be certain about how to use it. It is even worse when such >>> APIs are not properly documented (with is the case here). >>> I understand that the main issue is that no any DVB-enabled SoC vendor is interested in upstreaming theirs code, but I still hope it will change in near future(*) >>> We have one driver for a SoC DVB hardware at: >>> drivers/media/platform/sti/c8sectpfe/ >>> >>> I guess it still doesn't cover the entire SoC, but this is a WiP. If I >>> remember well, at the midia part of the SoC, they started by submitting >>> the Remote Controller code. >>> Without having full-featured DVB device in vanilla, we surely don't get some parts of DVB API covered. I can imagine that when somebody comes with such full-featured device he wants to reinvent just removed bits. >>> Re-adding the removed bits is easy. However, the API defined for >>> av7110 is old and it is showing its age: it assumes a limited number >>> of possible inputs/outputs. Modern SoC has a lot more ways link the >>> audio/video IP blocks than what the API provides. On a modern SoC, >>> not only DVB is supported, but also analog inputs (to support things >>> like composite input), cameras, HDMI inputs and even analog TV. >>> All of them interconnected to a media ISP. The current FF API can't >>> represent such hardware. >>> >>> The best API to represent those pipelines that exist on SoC for >>> multimedia is the media controller, where all IP blocks and their >>> links (whatever they are) can be represented, if needed. >>> >>> The audio and video DVB API is also too limited: it hasn't >>> evolved since when it was added. For audio, the ALSA API >>> allows a way more control of the hardware; for video, the >>> V4L2 API nowadays has all the bits to control video decoding >>> and encoding. Both APIs provide support for audio and video >>> inputs commonly found on those devices. >> The real advantage of the DVB audio/video/osd API is the possibility >> of frame synchronous audio/video/overlay output for high-quality >> audio/video playback, maybe with picture-in-picture functionality. >> >> Especially audio synchronization is not easy when the audio format >> changes from compressed audio (e.g. AC-3) to PCM (stereo), e.g. on >> HDMI output. While HDMI output hardware usually takes video frames and >> audio packets (and AVI info frames for audio/video format signalization) >> synchronously, V4L2 and
Inline emphasis warnings
Hi,
What is the suggested way(s) to fix this warning:
../kernel/sched/fair.c:7584: WARNING: Inline emphasis start-string without
end-string.
from this source:
* this CPU. The amount of the imbalance is returned in *imbalance.
I have a patch that changes that to env->imbalance, but what I am really looking
for is a way to include a '*' in the kernel-doc, for cases like this:
/**
* foofunc - do the bar and update its value
* @bar: pointer to input value, to be updated for return
*
* fu the *bar with baz
*/
void foofunc(unsigned long long *bar, unsigned long long baz)
{
*bar = *bar + 42 * baz;
*bar %= baz;
}
thanks.
--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] scripts: Add a script to find unused documentation
Add a script that finds files with kernel-doc comments for imported functions
that are not included anywhere in documentation.
Signed-off-by: sayli karnik
---
scripts/find-unused-docs.sh | 62 +
1 file changed, 62 insertions(+)
create mode 100755 scripts/find-unused-docs.sh
diff --git a/scripts/find-unused-docs.sh b/scripts/find-unused-docs.sh
new file mode 100755
index 000..3f46f89
--- /dev/null
+++ b/scripts/find-unused-docs.sh
@@ -0,0 +1,62 @@
+#!/bin/bash
+# (c) 2017, Jonathan Corbet
+# sayli karnik
+#
+# This script detects files with kernel-doc comments for exported functions
+# that are not included in documentation.
+#
+# usage: Run 'scripts/find-unused-docs.sh directory' from top level of kernel
+# tree.
+#
+# example: $scripts/find-unused-docs.sh drivers/scsi
+#
+# Licensed under the terms of the GNU GPL License
+
+if ! [ -d "Documentation" ]; then
+ echo "Run from top level of kernel tree"
+ exit 1
+fi
+
+if [ "$#" -ne 1 ]; then
+ echo "Usage: scripts/find-unused-docs.sh directory"
+ exit 1
+fi
+
+if ! [ -d "$1" ]; then
+ echo "Directory $1 doesn't exist"
+ exit 1
+fi
+
+cd "$( dirname "${BASH_SOURCE[0]}" )"
+cd ..
+
+cd Documentation/
+
+echo "The following files contain kerneldoc comments for exported functions \
+that are not used in the formatted documentation"
+
+# FILES INCLUDED
+
+files_included=($(grep -rHR ".. kernel-doc" --include \*.rst | cut -d " " -f
3))
+
+declare -A FILES_INCLUDED
+
+for each in "${files_included[@]}"; do
+ FILES_INCLUDED[$each]="$each"
+ done
+
+cd ..
+
+# FILES NOT INCLUDED
+
+for file in `find $1 -name '*.c'`; do
+
+ if [[ ${FILES_INCLUDED[$file]+_} ]]; then
+ continue;
+ fi
+ str=$(scripts/kernel-doc -text -export "$file" 2>/dev/null)
+ if [[ -n "$str" ]]; then
+ echo "$file"
+ fi
+ done
+
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
