关于unbound 的im_func属性

最新推荐文章于 2022-12-06 18:39:44 发布
原创 最新推荐文章于 2022-12-06 18:39:44 发布 · 859 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#im

因缺少博客内容，无法提取关键信息生成摘要。
18、Python 类的深入探索：方法、实例创建与属性处理
m0n1o2p的博客
07-01 39
本文深入探讨了 Python 类的核心机制，包括描述符与方法的基础知识、特殊类型的方法（类方法、静态方法）、实例的创建过程（__new__ 和 __init__ 的区别与应用）、属性的动态处理（__getattr__、__setattr__、__delattr__ 的使用），以及这些机制在实际编程中的应用场景。通过示例代码和流程图，帮助开发者更高效、灵活地使用 Python 类进行面向对象编程。
《Python 源码剖析》一些理解以及勘误笔记（2）
Meditation
04-28 2929
以下是本人阅读此书时理解的一些笔记，包含一些影响文义的笔误修正，当然不一定正确，贴出来一起讨论。 注：此书剖析的源码是2.5版本，在python.org 可以找到源码。纸质书阅读，pdf 贴图。 文章篇幅太长，故切分成2部分，这是第二部分。 p248: 嵌套函数、闭包和 decorator  co_cellvars: 通常是一个tuple，保存嵌套的作用域内
Unbound是一个验证，递归和缓存的DNS解析器。-C/C++开发
05-26
Unbound是一个验证，递归，缓存的DNS解析器。 它的设计既快捷又精巧，并基于开放标准融合了现代功能。 Unbound Unbound是一个验证，递归，缓存的DNS解析器。 它的设计既快捷又精巧，并融合了基于开放标准的现代功能。 如果您有任何反馈意见，我们很乐意听取您的意见。 不要犹豫，在Github上发布问题，或在未绑定邮件列表中发布消息。 您可以阅读我们的文档，以了解有关Unbound的更多信息。 编译确保已安装C工具链，OpenSSL及其包含文件和libexpat。 未绑定可以编译
实例方法的__func__属性的理解
xiaoyaGrace的博客
11-06 979
先摆一段代码: class A: def foo(self): pass bar = foo 1 2 3 4 明确一个概念: method 是一种 function，method 有一个__func__ 属性，指向一个 funct...
详解python自定义方法属性
weixin_33709590的博客
06-22 247
在python自定义方法中有一些只读属性，一般我们用不到，但是了解下也不错，通过这篇文章，我们还可以了解到==绑定方法==和==非绑定方法==的区别。 im_self 指代类的实例对象。 im_func 指代函数对象。 im_class 指代绑定方法的类或者调用非绑定方法的类。 __doc__ 方...
python函数及方法大全_Python中的函数与方法 以及python类机制
weixin_39624816的博客
01-29 532
函数与方法的区别随着我们越来越频繁使用Python, 我们难免会接触到类, 接触到类属性和方法.但是很多新手包括我, 不知道方法 和 函数 的区别,这次简单来讨论下, 如果有哪里认识不正确, 希望大神提点指教!先来看两个定义吧:function(函数) —— A series of statements which returns some value toa caller. It can als...
替换一个实例方法，没你想的那么简单~
罗罗攀
04-12 794
思路一：简单地替换 当你想对类实例的方法进行替换时，你可能想到的是直接对他进行粗暴地替换classPeople: defspeak(self): print(&...
Python自省（反射）指南
m0_72557783的博客
12-06 226
如下
Python自省（反射)详解
MXB_1220的博客
05-07 1987
目录 前言 1. 访问对象的属性 2. 访问对象的元数据 2.0. 准备工作：确定对象的类型 2.1. 模块(module) 2.2. 类(class) 2.3. 实例(instance) 2.4. 内建函数和方法(built-in functions and methods) 2.5. 函数(function) 2.6. 方法(method) 2.7. 生成器(generator) 2.8. 代码块(code) 2.9. 栈帧(frame) 2.10. 追踪(traceba
python2.3如何检索类中指定函数的入参,已经尝试kcs_pipe.part_respec.__doc__，输出None
06-24
另一种方法是解析函数的`__code__`属性，但在Python2.3中，函数有`func_code`属性（而不是`__code__`），我们可以从这个代码对象中获取信息。但是，对于类中的方法，我们需要先获取未绑定的方法（在Python2.3中，类...
笔记-python-反射
akuibpt23191的博客
10-04 248
笔记-python-反射 1. 反射 在很多地方看到自省和反射，很晕菜，整理了一下相关文档，加深了理解。 自省和反射其实说的是一件事，核心操作是根据输入去对象（模块）中调用（查找/获取/删除/添加）成员，一种基于字符串的事件驱动。 基本使用场景是不能确定对象中的成员有哪些，需要先试探对象中是否有这个成员，可否调用，然后才能调用。 反射是个很吓唬人的名词，听起来高深莫测，在...
Python魔术师--self
weixin_30569153的博客
06-26 452
(原文是 Python's Magical Self，来自http://concentricsky.com) Python的self参数有时真让人抓狂，比如，你必须在每一个类的方法里显示定义self，然后，它会霸占不需要它们的地方。 class Foo(object):...
Python自省（反射）指南以及self的简单介绍
急流勇进
03-21 700
文章来源：https://www.cnblogs.com/huxi/archive/2011/01/02/1924317.html 首先通过一个例子来看一下本文中可能用到的对象和相关概念。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ...
C++调试帮助--__func__的使用
QuinnHanz的博客
05-31 4984
__func__是编译器定义的一个局部静态变量（const char的一个静态数组），用于存放函数的名字。#include<iostream> using namespace std; const char* hello() {return __func__;} int main() { cout << " : in function " << __fu...
Python核心丨自定义函数
m0_45198298的博客
06-10 780
自定义函数 函数基础 函数就是为了实现某一个功能的代码段，只要写好以后，就可以重复利用。 def my_func(message): print('Get a message:{}'.format(message)) # 调用函数my_func() my_func('Hello World') # 输出 Get a message: Hello World def是函数的声明； my_func是函数的名称； 括号里的message则是函数的参数； 而print那行则是函数的主体部分，可以执行相
黄昏风景
mybirdsky的专栏
01-19 382
2006.8.29 08:21
Python Mixin技术介绍
weixin_30780221的博客
05-09 249
1. Mix-in技术介绍 Mixin可以译为混入，就是在不改变原对象的情况下对其进行扩展。本文介绍了在 Python 语言中，如何实现Mixin技术，及安装的相应技巧。 1.1. 什么是Mix-in技术 Mix- in技术，中文不知道应该如何称呼，但意思好象是混入。它的作用是，在运行期间,动态改变类的基类或类的方法，从而使得类的表现可以发生变化。可以用在一 个通用类接口中，根据不同的选择使用...
scala中的"unbound placeholder parameter"中的一种情况
辛星，前进的路上.
08-16 3276
在scala中，如果我们使用val型的变量使用下划线赋值的话，就会出现这种提示，如果是使用var型的变量，就不会有这种提示了。 操作范例如下: scala> val a: Int = _ :11: error: unbound placeholder parameter val a: Int = _ ^ scala> var a: Int
unbound：安装与配置
热门推荐
kanguolaikanguolaik的专栏
09-04 1万+
unbound是一个开源local dns，支持edns-client-subnet。
[ 216.128063] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: [ 216.133972] rcu: 1-...0: (25 ticks this GP) idle=589/1/0x4000000000000000 softirq=37/39 fqs=2585 [ 216.142921] (detected by 3, t=52546 jiffies, g=-1083, q=2) [ 216.148485] Task dump for CPU 1: [ 216.151696] task:kworker/u8:2 state:R running task stack: 0 pid: 93 ppid: 2 flags:0x0000000a [ 216.161601] Workqueue: events_unbound deferred_probe_work_func [ 216.167425] Call trace: [ 216.169855] __switch_to+0x10c/0x18c [ 216.173422] 0x0 [ 279.152064] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: [ 279.157970] rcu: 1-...0: (25 ticks this GP) idle=589/1/0x4000000000000000 softirq=37/39 fqs=3359 [ 279.166919] (detected by 3, t=68302 jiffies, g=-1083, q=2) [ 279.172483] Task dump for CPU 1: [ 279.175694] task:kworker/u8:2 state:R running task stack: 0 pid: 93 ppid: 2 flags:0x0000000a [ 279.185599] Workqueue: events_unbound deferred_probe_work_func [ 279.191423] Call trace: [ 279.193853] __switch_to+0x10c/0x18c [ 279.197420] 0x0 [ 342.176064] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: [ 342.181969] rcu: 1-...0: (25 ticks this GP) idle=589/1/0x4000000000000000 softirq=37/39 fqs=4113 [ 342.190918] (detected by 0, t=84058 jiffies, g=-1083, q=4) [ 342.196481] Task dump for CPU 1: [ 342.199693] task:kworker/u8:2 state:R running task stack: 0 pid: 93 ppid: 2 flags:0x0000000a [ 342.209597] Workqueue: events_unbound deferred_probe_work_func [ 342.215421] Call trace: [ 342.217851] __switch_to+0x10c/0x18c [ 342.221419] 0x0
最新发布
11-27
你提供的日志信息来自 Linux 内核的 **RCU (Read-Copy-Update)** 子系统，提示出现了 **CPU stall（CPU 停顿）** 问题。这类错误通常表明某个 CPU 长时间不响应 RCU 的宽限期（grace period），可能导致系统不稳定或性能下降。 --- ### 🔍 日志分析 ```log [ 216.128063] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: [ 216.133972] rcu: 1-...0: (25 ticks this GP) idle=589/1/0x4000000000000000 softirq=37/39 fqs=2585 [ 216.142921] (detected by 3, t=52546 jiffies, g=-1083, q=2) ``` - `rcu_sched detected stalls`：表示调度器级别的 RCU 检测到 CPU stall。 - `CPU 1` 出现了问题，已经持续了 **25 个 tick**（通常是 25ms 或更久，取决于 HZ 设置）没有完成 RCU 宽限期。 - `idle=589/1` 表示这个 CPU 上一次进入 idle 是在 589 个滴答之前。 - `softirq=37/39` 表示 softirq 处理次数，可能说明 softirq 被压制。 - `fqs=2585`：强制静默（force_quiescent_state）调用次数。 - `detected by 3`：CPU 3 检测到了 CPU 1 的停滞。 - `g=-1083`：当前宽限期编号为负，说明严重滞后。 - `q=2`：有 2 个未处理的 RCU 回调。 接下来是任务转储： ```log task:kworker/u8:2 state:R running task Workqueue: events_unbound deferred_probe_work_func Call trace: __switch_to+0x10c/0x18c 0x0 ``` - 进程名：`kworker/u8:2` —— 一个内核工作队列线程（unbound 类型）。 - 正在执行的工作函数：`deferred_probe_work_func` - 状态为 `R`（运行中），但卡住了。 - 调用栈非常浅，只看到上下文切换，说明它可能正在频繁被抢占或陷入死循环/无限延迟。 --- ## ✅ 可能原因与解决方案 ### 📌 原因 1：`deferred_probe_work_func` 卡住 这是最常见的原因之一。该函数用于设备模型中的“延迟探测”机制（如驱动尚未加载时推迟设备绑定）。如果某些硬件驱动无法完成初始化，或者存在资源竞争、死锁、无限重试等问题，会导致此工作项长期运行。 #### 解决方案： 1. **检查设备树或模块加载顺序** - 确保所有依赖的设备驱动已正确加载。 - 使用 `dmesg | grep -i probe` 查看是否有失败的设备探测记录。 ```bash dmesg | grep -i "deferred" dmesg | grep -i "probe" ``` 2. **避免驱动阻塞行为** - 不应在 `deferred_probe` 中做耗时操作或等待外部事件。 - 改用 schedule_delayed_work 并设置超时重试机制。 3. **添加调试输出** 在你的驱动代码中，在 `deferred_probe_work_func` 开始和结束处加打印： ```c void deferred_probe_work_func(struct work_struct *work) { pr_info("Starting deferred probe...\n"); // ... probing logic ... pr_info("Deferred probe finished.\n"); } ``` --- ### 📌 原因 2：禁用了抢占或长时间关闭中断 RCU 依赖于每个 CPU 定期进入“quiescent state”（如调度点、用户态执行等）。如果某个 CPU 长时间处于原子上下文（中断处理、自旋锁持有、preempt_disable() 区域），就会导致 RCU stall。 #### 检查方法： - 查看是否在中断上下文中做了大量工作。 - 是否使用了 `while(1)` 循环而未调用 `cond_resched()`。 - 是否有驱动在 `atomic context` 执行睡眠操作。 #### 解决方案： 将长任务移到 workqueue 或 tasklet 中： ```c // 错误示例：在中断中长时间处理 irqreturn_t my_irq_handler(int irq, void *dev_id) { // do something heavy here — BAD! while (condition) { // busy loop without rescheduling } return IRQ_HANDLED; } ``` ✅ 正确做法： ```c static DECLARE_WORK(my_work, heavy_work_function); irqreturn_t my_irq_handler(int irq, void *dev_id) { schedule_work(&my_work); // 推迟到 workqueue return IRQ_WAKE_THREAD; } ``` 并在 work 函数中处理繁重任务。 --- ### 📌 原因 3：系统负载过高或 CPU 资源不足 特别是在嵌入式系统或多核系统上，某个核心被独占使用，其他内核服务（如 RCU）得不到运行机会。 #### 解决方案： - 使用 `top`, `htop` 观察 CPU 使用率。 - 检查 `kworker` 是否占用过高 CPU。 - 考虑隔离 CPU（通过 `isolcpus=` 启动参数）来保留专用核心。 --- ### 📌 原因 4：内核配置不当 某些内核选项会影响 RCU 行为： | 配置项 | 推荐值 | 说明 | |-------|--------|------| | `CONFIG_RCU_CPU_STALL_TIMEOUT` | 30~60 秒 | 默认是 21 秒，太短可在调试时掩盖问题 | | `CONFIG_PREEMPT` | y | 启用可抢占内核减少 stall 风险 | | `CONFIG_NO_HZ_FULL` | y | 减少 tick，但需注意 user-idle 管理 | 你可以通过以下命令查看当前配置： ```bash grep CONFIG_RCU_CPU_STALL_TIMEOUT /boot/config-$(uname -r) ``` --- ### 🛠️ 临时缓解措施（调试期间） 你可以通过内核启动参数调整 RCU 行为： ```bash # 增加 stall 检测超时时间（单位：秒） rcu_cpu_stall_timeout=60 # 关闭 stall 检测（仅用于测试！不要生产环境使用） rcu_cpu_stall_suppress ``` 添加方式：修改 `/etc/default/grub` 中的 `GRUB_CMDLINE_LINUX`： ```conf GRUB_CMDLINE_LINUX="... rcu_cpu_stall_timeout=60" ``` 然后更新 grub： ```bash sudo update-grub ``` --- ## 💡 总结建议 1. **定位具体驱动**：找出哪个设备触发了 `deferred_probe_work_func`。 2. **避免长时间运行原子上下文代码**。 3. **启用内核调试功能**（如 `CONFIG_DEBUG_ATOMIC_SLEEP`）帮助发现问题。 4. **升级内核版本**：旧版内核可能存在已知 bug。 5. **使用 ftrace 分析调度行为**： ```bash echo function > /sys/kernel/debug/tracing/current_tracer echo 1 > /sys/kernel/debug/tracing/tracing_on # reproduce issue cat /sys/kernel/debug/tracing/trace ``` --- ### 示例：安全的延迟探测实现（带超时） ```c #include <linux/workqueue.h> #include <linux/delay.h> static struct delayed_work deferred_probe_work; void deferred_probe_worker(struct work_struct *work) { int ret; ret = device_probe(); // 实际探测逻辑 if (ret == -EPROBE_DEFER) { static int retries = 0; if (retries++ < 5) { pr_info("Re-scheduling deferred probe (%d)\n", retries); msleep(1000); // 等待 1s 再试 schedule_delayed_work(&deferred_probe_work, HZ); return; } else { pr_err("Too many deferred probe attempts, giving up\n"); } } if (!ret) pr_info("Device successfully probed\n"); } // 初始化时注册 INIT_DELAYED_WORK(&deferred_probe_work, deferred_probe_worker); schedule_delayed_work(&deferred_probe_work, HZ); ``` ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值