>>> {
>>> - int cpu, hk_flags;
>>> + static DEFINE_SPINLOCK(spread_lock);
>>> + static bool used[MAX_NUMNODES];
>>
>> I thought I mentioned this last time. How large is this array? How
>> large would it be if it were a nodemask_t? Would this be less code if
>
> Apologies that I forgot to
On 11/17/20 6:54 PM, Shaokun Zhang wrote:
> From: Yuqi Jin
>
> In multi-processor and NUMA system, I/O driver will find cpu cores that
> which shall be bound IRQ. When cpu cores in the local numa have been
> used up, it is better to find the node closest to the local numa node
> for performance,
On 11/15/20 11:59 PM, Shaokun Zhang wrote:
>> Do you want to take another pass at submitting this patch?
> 'Another pass'? Sorry for my bad understading, I don't follow it correctly.
Could you please incorporate the feedback that I've given about this
version of the patch and write a new version?
On 11/12/20 6:06 PM, Shaokun Zhang wrote:
>>> On Huawei Kunpeng 920 server, there are 4 NUMA node(0 - 3) in the 2-cpu
>>> system(0 - 1). The topology of this server is followed:
>>
>> This is with a feature enabled that Intel calls sub-NUMA-clustering
>> (SNC), right? Explaining *that* feature wou
On 11/12/20 5:53 PM, Jakub Kicinski wrote:
>> I do agree, though, that it's confusing *what* they reported, especially
>> if the patch in question is fixing something *else*. Rather than invent
>> a new tag, maybe a comment would suffice:
>>
>> Reported-by: kernel test robot # bug in earlier revi
On 11/12/20 4:24 PM, Jakub Kicinski wrote:
> On Wed, 11 Nov 2020 09:34:24 +0800 kernel test robot wrote:
>> If you fix the issue, kindly add following tag as appropriate
>> Reported-by: kernel test robot
> Good people of kernel test robot, could you please rephrase this to say
> that the tag is on
On 11/3/20 5:39 AM, Shaokun Zhang wrote:
> Currently, Intel DDIO affects only local sockets, so its performance
> improvement is due to the relative difference in performance between the
> local socket I/O and remote socket I/O.To ensure that Intel DDIO’s
> benefits are available to applications wh
On 10/12/20 9:19 AM, Eric Biggers wrote:
> On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
>>> And I still don't really understand. After this patchset, there is still
>>> code
>>> nearly identical to the above (doing a temporary mapping just for a memcpy)
>>> that
>>> would still be
Kent Overstreet had a patch set to completely remove flex arrays:
20180907165635.8469-7-kent.overstr...@gmail.com
I wonder where that set went.
From: Dave Hansen
I'm seeing warnings on kernel configurations where CONFIG_PM is
disabled. It happens in 4.12, at least:
drivers/ethernet/intel/igb/igb_main.c:7988:13: warning:
'igb_deliver_wake_packet' defined but not used [-Wunused-function]
This is because igb_deliver_w
On 10/19/2016 10:01 AM, Michal Hocko wrote:
> The question I had earlier was whether this has to be an explicit FOLL
> flag used by g-u-p users or we can just use it internally when mm !=
> current->mm
The reason I chose not to do that was that deferred work gets run under
a basically random 'curr
On 10/19/2016 02:07 AM, Michal Hocko wrote:
> On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
>> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
>>> I am wondering whether we can go further. E.g. it is not really clear to
>>> me whether we need an explicit FOLL_REMOTE when we can in
On 08/31/2015 02:26 PM, Dave Hansen wrote:
> From: Dave Hansen
>
> I have a .config with CONFIG_PM disabled. I get the following whenever
> compiling the e1000 driver:
>
> ...net/ethernet/intel/e1000e/netdev.c:6450:13: warning:
> 'e1000e_disable_aspm_locked'
From: Dave Hansen
I have a .config with CONFIG_PM disabled. I get the following whenever
compiling the e1000 driver:
...net/ethernet/intel/e1000e/netdev.c:6450:13: warning:
'e1000e_disable_aspm_locked' defined but not used [-Wunused-function]
static void e1000e_disable_aspm_loc
On Mon, 2008-02-18 at 11:00 +0100, Jan-Bernd Themann wrote:
> Dave Hansen <[EMAIL PROTECTED]> wrote on 15.02.2008 17:55:38:
>
> > I've been thinking about that, and I don't think you really *need* to
> > keep a comprehensive map like that.
> >
On Fri, 2008-02-15 at 14:22 +0100, Christoph Raisch wrote:
> A translation from kernel to ehea_bmap space should be fast and
> predictable
> (ruling out hashes).
> If a driver doesn't know anything else about the mapping structure,
> the normal solution in kernel for this type of problem is a multi
On Thu, 2008-02-14 at 09:36 -0800, Badari Pulavarty wrote:
>
> I am not sure what you are trying to do with walk_memory_resource().
> The
> behavior is different on ppc64. Hotplug memory usage assumes that all
> the memory resources (all system memory, not just IOMEM) are
> represented
> in /proc
On Thu, 2008-02-14 at 09:46 +0100, Christoph Raisch wrote:
> Dave Hansen <[EMAIL PROTECTED]> wrote on 13.02.2008 18:05:00:
> > On Wed, 2008-02-13 at 16:17 +0100, Jan-Bernd Themann wrote:
> > > Constraints imposed by HW / FW:
> > > - eHEA has own MMU
> > >
On Wed, 2008-02-13 at 16:17 +0100, Jan-Bernd Themann wrote:
> Constraints imposed by HW / FW:
> - eHEA has own MMU
> - eHEA Memory Regions (MRs) are used by the eHEA MMU to translate virtual
> addresses to absolute addresses (like DMA mapped memory on a PCI bus)
> - The number of MRs is limited
On Mon, 2008-02-11 at 17:24 +0100, Jan-Bernd Themann wrote:
> Drivers like eHEA need memory notifiers in order to
> update their internal DMA memory map when memory is added
> to or removed from the system.
>
> Patch for eHEA memory hotplug support that uses these functions:
> http://www.spinics.
On Mon, 2008-02-11 at 17:24 +0100, Jan-Bernd Themann wrote:
> Drivers like eHEA need memory notifiers in order to
> update their internal DMA memory map when memory is added
> to or removed from the system.
>
> Patch for eHEA memory hotplug support that uses these functions:
> http://www.spinics.
On Mon, 2008-02-11 at 17:24 +0100, Jan-Bernd Themann wrote:
> the eHEA patch belongs to a patchset that is usually
> added by Jeff Garzik once this dependency (EXPORTS)
> is resolved.
I know that's already in mainline but, man, that code is nasty. It has
stuff indented 7 levels or so and is vi
On Mon, 2008-02-11 at 16:57 +0100, Jan-Bernd Themann wrote:
> Drivers like eHEA need memory notifiers in order to
> update their internal DMA memory map when memory is added
> to or removed from the system.
Could you post this with the new users as well so we can make sure
they're not abusing thi
On Mon, 2008-02-11 at 10:49 +0100, Jan-Bernd Themann wrote:
> are you the right person to address this patch to?
You might want to check the top of the file. ;)
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb
On Tue, 2006-08-15 at 18:48 +0400, Andrey Savochkin wrote:
>
> /* Can survive without statistics */
> stats = kmalloc(sizeof(struct net_device_stats), GFP_KERNEL);
> if (stats) {
> memset(stats, 0, sizeof(struct net_device_stats));
> - loopback
On Wed, 2006-06-28 at 00:52 +0200, Herbert Poetzl wrote:
> seriously, what I think Eric meant was that it
> might be nice (especially for migration purposes)
> to keep the device namespace completely virtualized
> and not just isolated ...
It might be nice, but it is probably unneeded for an initi
I've noticed two oopses with a git tree I pulled yesterday. Last
commit: 4706df3d3c42af802597d82c8b1542c3d52eab23
Probably the same bug as the one that Andrew Morton forwarded here:
http://marc.theaimsgroup.com/?l=linux-netdev&m=112618307911533&w=2
I see a bunch of assertion failures, followed
.6.13-rc1-mm1.
-- Dave
Signed-off-by: Dave Hansen <[EMAIL PROTECTED]>
diff -ru linux-2.6-mm.orig/drivers/net/wireless/hostap/hostap.c
linux-2.6-mm/drivers/net/wireless/hostap/hostap.c
--- linux-2.6-mm.orig/drivers/net/wireless/hostap/hostap.c 2005-07-15
10:57:18.0 -0700
+++ linux
28 matches
Mail list logo
