linux-kernel - Re: [RFC PATCH 4/4 v0.3] sched/umcg: RFC: implement UMCG syscalls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 19 Jul 2021 14:13:05 -0400
From:   Thierry Delisle <tdelisle@...terloo.ca>
To:     Peter Oskolkov <posk@...gle.com>
CC:     <posk@...k.io>, <avagin@...gle.com>, <bsegall@...gle.com>,
        <jannh@...gle.com>, <jnewsome@...project.org>,
        <joel@...lfernandes.org>, <linux-api@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <mingo@...hat.com>,
        <peterz@...radead.org>, <pjt@...gle.com>, <tglx@...utronix.de>,
        Peter Buhr <pabuhr@...terloo.ca>
Subject: Re: [RFC PATCH 4/4 v0.3] sched/umcg: RFC: implement UMCG syscalls

 > Latency/efficiency: on worker wakeup an idle server can be picked from
 > the list and context-switched into synchronously, on the same CPU.
 > Using FDs and select/poll/epoll will add extra layers of abstractions;
 > synchronous context-switches (not yet fully implemented in UMCG) will
 > most likely be impossible. This patchset seems much more efficient and
 > lightweight than whatever can be built on top of FDs.

I can believe that.

Are you planning to support separate scheduling instances within a 
single user
space? That is having multiple sets of server threads and workers can 
only run
within a specific set.

I believe the problem with the idle_servers_ptr as specified is that it 
is not
possible to reclaim used nodes safely. I don't see any indication of which
nodes the kernel can concurrently access and on which some memory 
reclamation
scheme could be based.

What is the benefit of having users maintain themselves a list of idle 
servers
rather than each servers marking themselves as 'out of work' and having the
kernel maintain the list?