linux-kernel - IRQ affinities (was: boot cgroup questions)

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]

Message-Id: <20080509061727.5057de1f.pj@sgi.com>
Date:	Fri, 9 May 2008 06:17:27 -0500
From:	Paul Jackson <pj@....com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	maxk@...lcomm.com, menage@...gle.com, mingo@...e.hu,
	linux-kernel@...r.kernel.org
Subject: IRQ affinities (was: boot cgroup questions)

Peter wrote:
> That's a new feature; and its quite common that new features require
> code changes.

It's common for new features to require code changes to take advantage
of the new features.

It's less desirable that taking advantage of such new features breaks
existing, basically unrelated, code.

My gut sense is that, in a misguided effort to find a "simple" answer
to irq distribution, we (well, y'all) are trying to attach this
feature to cpusets or cgroups.

Let me ask a different question:

  What solutions would you (Max, Peter, Ingo, lurkers, ...) be
  suggesting for this 'IRQ affinity' problem if cpusets and
  cgroups didn't exist in any form whatsoever?

The answer to that question might help me contribute to this discussion
in another way ... it might help me understand better what we're really
trying to do here.  You guys were proposing mechanisms that don't fit
my architecture sense of cpusets, but I was having problems figuring out
what are the essential underlying requirements, independent of choice
of mechanism.

Perhaps by describing one or two possible alternative, cpuset-free,
mechanisms that come more or less close to meeting our needs, I will
glean a better understanding of these elusive requirements, and can
better contribute to the discussion of design trade offs facing us.

So could you describe some possible cpuset-free solutions?  If they are
flawed in some critical way, that's ok, just point out said flaw(s).
Either way, this could help illuminate what's needed here.

It might be, once I better understand the requirements, possible
solutions and their tradeoffs, that I come to agree that cpusets or
cgroups present the best mechanism, given the tradeoffs and what's
needed.  Or it might be we find a better way to meet our needs.

Actually, if for no other reason than to bring any lurkers up to speed,
if you (Max or Peter, likely) wanted to describe, from the beginning,
what this discussion is about, that would be good too.  I doubt anyone
outside of three or four of us even recalls that long discussion of
February and March, 2008.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@....com> 1.940.382.4214
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/