ARD=malta TEST=prepare
>
> * Test kernel modules
>
> $ make test modules=ldt
>
> * Debug kernel (start qemu with gdbstub and running gdb with default
> .gdbinit)
>
> $ make debug
>
> More usage please refer to the README.md of this project:
>
> https://github.com/tinyclub/linux-lab/blob/master/README.md
>
> Let's take a look at the demonstration:
>
> * Showterm demonstration
> http://showterm.io/6fb264246580281d372c6
>
> * Showdesk demonstration
> http://showdesk.io/7977891c1d24e38dffbea1b8550ffbb8/?f=1
>
> * Try it online (only one account, update in 30 minutes)
> http://tinylab.cloud:6080/labs/
>
> This project is still in development stage, it is not yet for product level.
>
> Enjoy and Welcome your feedback.
>
> Thanks & BR,
> Falcon
>
--
Regards,
- cee1
(where n denotes
periods passed since rq->age_stamp)?
- It will be a big summed value if next will meet the end of current
period, assuming several RT tasks are running
- But it will suddenly reduce to 1/2^n if just passed several periods
So, what is the math behind sched_avg_update()?
--
Regards,
- cee1
unmapped_area() tries to find an unmapped area between info.low_limit and
info.high_limit:
info.low_limit info.high_limit
^ ^
| |
_|__
link sockets of NETLINK_KOBJECT_UEVENT, but some processes
consume uevent __too slow__, and uevent is continually triggered. Will
the system block? Or those processes finally lost some uevents?
3. Watch a directory via inotify, but some processes consume events
__too slow__, and file operations is
2015-08-01 5:15 GMT+08:00 Andy Lutomirski :
> On Fri, Jul 31, 2015 at 9:25 AM, cee1 wrote:
>> 2015-07-31 2:12 GMT+08:00 Andy Lutomirski :
>>>
>>> I find myself wondering whether an in-kernel *bus* is a good idea at
>>> all. Creating a bus that unprivileged p
(control message) and setting up
a proper eBPF.
Next time, the bus endpoint sends to maddr2, the kernel will allow this if:
1) maddr1 & maddr2 == maddr1
And 2) the eBPF allows it.
(i.e. the same multicast match logic in this AF_BUS)
--
Regards,
- cee1
--
To unsubscribe from this list: sen
* Multicast addresses (last char of sbus_path is '*')
* Kernel notification addr (sbus_addr == NULL)
4. Bloom filters friendly. (i.e. the multicast logic)
2015-07-30 21:09 GMT+08:00 cee1 :
> Hi all,
>
> I'm interested in the idea of AF_BUS.
>
> There have already be
some data if the producer produces too
fast(or the consumers consume too slow). What it needs may be a chance
for recipients to know some broadcast data lost.
--
Regards,
- cee1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to major
API.
## Other thoughts
1. The bus master may want to receive notifications from the kernel,
such as "a bus endpoint died". A special sockaddr_bus "{
.sbus_addr_ncomp = 0, .sbus_addr = NULL }" indicates a message from
kernel.
2. A bus endpoint may pass a memfd to another bus end
of getting a list
> of a few of them to copy data to. Of course for small number of
> receivers the "constant" cost of running the Bloom filter may be higher.
Still think about the idea of implementing KDBUS in the form of socket.
What about using __multicast group__ instead of EBPF, to send/receive
multicast message?
(Which can implement the bloom filter as follows ?) E.g.
Sender:
send to multi_address
Receivers:
if ((multi_address & joined_address) == joined_address) {
/* a message for us */
}
Then we can further apply EBFP to remove the "False positive" case,
which will otherwise wake up user space code, and let it clear "False
positive" case.
--
Regards,
- cee1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
10 matches
Mail list logo
