All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Travis <travis@sgi.com>
To: Jiri Slaby <jirislaby@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: cpu4096 + smp_affinity breakage
Date: Tue, 29 Jul 2008 08:03:36 -0700	[thread overview]
Message-ID: <488F3148.2050500@sgi.com> (raw)
In-Reply-To: <488F2A65.2090405@gmail.com>

Jiri Slaby wrote:
> Hi,
> 
> I see cpu4096 branches in -tip. Do you know about
> /proc/irq/*/*smp_affinity (irq_affinity_read_proc,
> default_affinity_read) breakage with NR_CPUS=4096? Reading by `cat' from
> those files fails due to bitmap sent out is about 1150 bytes, but cat
> provides only 1024B sized buffer. Can you think about any fix for this?
> 
> Using file offset and utilize only portion of that buffer returned to
> the userspace will break atomicity I guess (does this matter?). If we
> get a snapshot, it would get old if some reader breaks up. And if we use
> per-reader buffer, we will be unable to free it. Any ideas?
> 
> I think the same problem is for not-at-once-writes.

The best alternate is to use cpulist_scnprintf but even this has
problems in the worst pathological case (where you want every other
cpu listed, e.g. only one of the two hyper threads).  Another alternate
would be to send only nr_cpu_ids mask bits [with obviously some way
for the user to discover what nr_cpu_ids is.]

There was strong objections to changing any of the /sys interfaces, but
I don't know what the rules are for the /proc interfaces.  And (iirc),
overflow was the user's responsibility.  How about using "dd bs=4k ..."?

Thanks,
Mike

  reply	other threads:[~2008-07-29 15:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-29 14:34 cpu4096 + smp_affinity breakage Jiri Slaby
2008-07-29 15:03 ` Mike Travis [this message]
2008-07-29 15:05 ` Alexey Dobriyan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=488F3148.2050500@sgi.com \
    --to=travis@sgi.com \
    --cc=jirislaby@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.