On __fget_light function issue

[asu]

Bellow is result of perf record:
__fget_light /proc/kcore
       │ ↓ je 30
       │ push %rbp
       │ mov %rsp,%rbp
       │ callq 0xffffffff8122a6a0
       │ test %rax,%rax
       │ ↓ je 54
  0,83 │ or $0x1,%rax
       │ pop %rbp
       │ ← retq
       │30: mov 0x20(%rax),%rax
  1,65 │ cmp (%rax),%edi
  0,83 │ ↓ jae 51
  0,83 │ mov 0x8(%rax),%rax
  0,83 │ mov %edi,%edi
       │ lea (%rax,%rdi,8),%rax
  2,48 │ mov (%rax),%rax
  2,48 │ test %rax,%rax
       │ ↓ je 51
       │ test %esi,0x44(%rax)
 70,25 │ ┌──jne 51
       │ │ repz retq
       │51:└─→xor %eax,%eax
       │ ← retq
       │54: xor %eax,%eax
       │ pop %rbp
       │ ← retq

and i attached one patch wich descrease from 70-100 cycles stall to 23 cycles stall on function.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: linux-image-4.4.0-28-generic 4.4.0-28.47
ProcVersionSignature: Ubuntu 4.4.0-28.47-generic 4.4.13
Uname: Linux 4.4.0-28-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: asu 2742 F.... pulseaudio
CurrentDesktop: MATE
Date: Wed Jun 29 18:50:46 2016
InstallationDate: Installed on 2016-04-29 (61 days ago)
InstallationMedia: Ubuntu-Studio 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
IwConfig:
 lo no wireless extensions.

 enp1s0 no wireless extensions.
MachineType: Olidata S.p.A. ALABAMA
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-28-generic root=/dev/mapper/192--168--0--108--vg-root ro
RelatedPackageVersions:
 linux-restricted-modules-4.4.0-28-generic N/A
 linux-backports-modules-4.4.0-28-generic N/A
 linux-firmware 1.157.1
RfKill:

SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/08/2008
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: S0101
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: To be filled by O.E.M.
dmi.board.vendor: To be filled by O.E.M.
dmi.board.version: To be filled by O.E.M.
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrS0101:bd07/08/2008:svnOlidataS.p.A.:pnALABAMA:pvrToBeFilledByO.E.M.:rvnTobefilledbyO.E.M.:rnTobefilledbyO.E.M.:rvrTobefilledbyO.E.M.:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: ALABAMA
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: Olidata S.p.A.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Can you provide some information on the status of the patch with regards to getting it merged upstream? Has it been sent upstream, what sort of feedback has it received, is it getting applied to a subsystem maintainer's tree, etc?

People affected by this bug are probably wondering why the kernel team doesn't just apply the patch and fix it. The reason is that the kernel team is reluctant (not opposed) to apply any patch to a stable kernel that is not from upstream. Applying patches that don't come from upstream add greatly to the support of the kernel as other upstream patches may touch the same area as the non-upstream patch and may prevent them from applying cleanly.

To submit your patch, send your patch with the detailed description/changelog and your Signoff (ending with Signed-off-by: your name <email>), to the emails listed from ./scripts/get_maintainer.pl drivers/SUBSYSTEM-DETAILS (the get_maintainer.pl is from the kernel sources). Once you have sent the patch upstream and it's accepted, please drop a note here so that we can cherry-pick/include the patch into Ubuntu kernel.