| /linux/tools/perf/pmu-events/arch/x86/jaketown/ |
| H A D | uncore-interconnect.json | 532 …therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for e…
542 …therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for e…
552 …therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for e…
562 …therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for e…
572 …therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for e…
582 …therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for e…
592 …therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for e…
602 …therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for e…
612 …therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for e…
622 …therefore it takes twice as many fits to transmit a flit. When one talks about QPI 'speed' (for e…
[all …]
|
| /linux/tools/perf/pmu-events/arch/x86/ivytown/ |
| H A D | uncore-interconnect.json | 236 … re-acquire it later when they get to the head of the queue. This will therefore track the number…
993 …therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for exa…
1003 …therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for exa…
1013 …therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for exa…
1023 …therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for exa…
1033 …therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for exa…
1043 …therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for exa…
1053 …therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for exa…
1063 …therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for exa…
1073 …therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for exa…
[all …]
|
| /linux/tools/perf/pmu-events/arch/x86/haswellx/ |
| H A D | uncore-interconnect.json | 953 "PublicDescription": "Counts the number of flits received from the QPI Link. It includes filters for Idle, protocol, and Data Flits. Each flit is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four fits, each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for example, 8.0 GT/s), the transfers here refer to fits. Therefore, in L0, the system will transfer 1 flit at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as data bandwidth. For example, when we are transferring a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual data and an additional 16 bits of other information. To calculate data bandwidth, one should therefore do: data flits * 8B / time (for L0) or 4B instead of 8B for L0p.; Number of flits received over QPI that do not hold protocol payload. When QPI is not in a power saving state, it continuously transmits flits across the link. When there are no protocol flits to send, it will send IDLE and NULL flits across. These flits sometimes do carry a payload, such as credit returns, but are generally not considered part of the QPI bandwidth.",
963 "PublicDescription": "Counts the number of flits received from the QPI Link. This is one of three groups that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each flit is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four fits, each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for example, 8.0 GT/s), the transfers here refer to fits. Therefore, in L0, the system will transfer 1 flit at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as data bandwidth. For example, when we are transferring a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual data and an additional 16 bits of other information. To calculate data bandwidth, one should therefore do: data flits * 8B / time.; Counts the total number of flits received over QPI on the DRS (Data Response) channel. DRS flits are used to transmit data with coherency. This does not count data flits received over the NCB channel which transmits non-coherent data.",
973 "PublicDescription": "Counts the number of flits received from the QPI Link. This is one of three groups that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each flit is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four fits, each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for example, 8.0 GT/s), the transfers here refer to fits. Therefore, in L0, the system will transfer 1 flit at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as data bandwidth. For example, when we are transferring a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual data and an additional 16 bits of other information. To calculate data bandwidth, one should therefore do: data flits * 8B / time.; Counts the total number of data flits received over QPI on the DRS (Data Response) channel. DRS flits are used to transmit data with coherency. This does not count data flits received over the NCB channel which transmits non-coherent data. This includes only the data flits (not the header).",
983 "PublicDescription": "Counts the number of flits received from the QPI Link. This is one of three groups that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each flit is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four fits, each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore i
[all...] |
| /linux/tools/perf/pmu-events/arch/x86/broadwellx/ |
| H A D | uncore-interconnect.json | 952 "PublicDescription": "Counts the number of flits received from the QPI Link. It includes filters for Idle, protocol, and Data Flits. Each flit is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four fits, each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for example, 8.0 GT/s), the transfers here refer to fits. Therefore, in L0, the system will transfer 1 flit at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as data bandwidth. For example, when we are transferring a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual data and an additional 16 bits of other information. To calculate data bandwidth, one should therefore do: data flits * 8B / time (for L0) or 4B instead of 8B for L0p.; Number of flits received over QPI that do not hold protocol payload. When QPI is not in a power saving state, it continuously transmits flits across the link. When there are no protocol flits to send, it will send IDLE and NULL flits across. These flits sometimes do carry a payload, such as credit returns, but are generally not considered part of the QPI bandwidth.",
962 "PublicDescription": "Counts the number of flits received from the QPI Link. This is one of three groups that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each flit is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four fits, each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for example, 8.0 GT/s), the transfers here refer to fits. Therefore, in L0, the system will transfer 1 flit at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as data bandwidth. For example, when we are transferring a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual data and an additional 16 bits of other information. To calculate data bandwidth, one should therefore do: data flits * 8B / time.; Counts the total number of flits received over QPI on the DRS (Data Response) channel. DRS flits are used to transmit data with coherency. This does not count data flits received over the NCB channel which transmits non-coherent data.",
972 "PublicDescription": "Counts the number of flits received from the QPI Link. This is one of three groups that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each flit is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four fits, each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for example, 8.0 GT/s), the transfers here refer to fits. Therefore, in L0, the system will transfer 1 flit at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as data bandwidth. For example, when we are transferring a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual data and an additional 16 bits of other information. To calculate data bandwidth, one should therefore do: data flits * 8B / time.; Counts the total number of data flits received over QPI on the DRS (Data Response) channel. DRS flits are used to transmit data with coherency. This does not count data flits received over the NCB channel which transmits non-coherent data. This includes only the data flits (not the header).",
982 "PublicDescription": "Counts the number of flits received from the QPI Link. This is one of three groups that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each flit is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four fits, each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore i
[all...] |
| /linux/drivers/pci/controller/dwc/ |
| H A D | Kconfig | 50 DesignWare IP and therefore the driver re-uses the DesignWare
61 and therefore the driver re-uses the DesignWare core functions to
108 on DesignWare hardware and therefore the driver re-uses the
120 on DesignWare hardware and therefore the driver re-uses the
223 DesignWare hardware and therefore the driver re-uses the
377 hardware and therefore the driver re-uses the DesignWare core
497 DesignWare hardware and therefore the driver re-uses the
509 on DesignWare hardware and therefore the driver re-uses the
|
| /linux/Documentation/networking/device_drivers/hamradio/ |
| H A D | baycom.rst | 22 therefore it supports just about every bit bang modem on a
65 and can therefore be fed from the parallel port and does not require
89 but they are now true kernel network interfaces. Installation is therefore
143 a reasonable DCD algorithm in software. Therefore, if your radio
159 startup time. Therefore the baycom drivers subsequently won't be able to
160 access a serial port. You might therefore find it necessary to release
|
| /linux/Documentation/networking/ |
| H A D | x25.rst | 15 I therefore decided to write the implementation such that as far as the
17 layer of the Linux kernel and therefore it did not concern itself with
18 implementation of LAPB. Therefore the LAPB modules would be called by
|
| H A D | xsk-tx-metadata.rst | 16 length is therefore the same for every socket that shares the same umem.
82 packets in the same Tx Queue until it is sent. Therefore, it is recommended
106 PTP time (bits[39:8]) and rolls over after 256 seconds. Therefore, the
122 set to schedule the packet for the next Qbv cycle. Therefore, the horizon
|
| H A D | gtp.rst | 165 There is only one GTP-U entity (and therefore SGSN/GGSN/S-GW/PDN-GW
173 Therefore:
189 Therefore no two remote GTP-U endpoints shall send traffic to a
199 Therefore, the receiving side identifies tunnels exclusively based on
242 Therefore for a given UE the mapping in IP to PDN network is:
|
| /linux/tools/memory-model/Documentation/ |
| H A D | control-dependencies.txt | 5 do not support them. One purpose of this document is therefore to
12 Therefore, a load-load control dependency will not preserve ordering
91 have been applied. Therefore, if you need ordering in this example,
134 The compiler is therefore within its rights to transform the above code
144 is gone, and the barrier won't bring it back. Therefore, if you need
257 (*) Compilers do not understand control dependencies. It is therefore
|
| /linux/Documentation/mm/ |
| H A D | highmem.rst | 83 temporarily mapped. Therefore, users may call a plain page_address()
95 therefore try to design their code to avoid the use of kmap() by mapping
118 the issuing task is therefore required to stay on that CPU until it has
126 and disable pagefaults. This could be a source of unwanted latency. Therefore
149 available. Therefore, kmap() is only callable from preemptible context.
|
| /linux/drivers/net/ovpn/ |
| H A D | socket.c | 142 /* a TCP socket can only be owned by a single peer, therefore there in ovpn_socket_new()
173 * therefore we can increase the refcounter and in ovpn_socket_new()
204 * therefore we increase its refcounter. in ovpn_socket_new()
221 /* TCP sockets are per-peer, therefore they are linked to their unique in ovpn_socket_new()
|
| /linux/arch/arm/boot/dts/nxp/imx/ |
| H A D | imx6qdl-dhcom-drc02.dtsi | 15 * Tx and Rx are routed to the DHCOM UART1 rts/cts pins. Therefore the micro SD
73 * DHCOM UART1 rts/cts pins. Therefore this UART have to use DHCOM GPIOs
119 * Therefore, they have been removed from the list below.
|
| /linux/include/linux/platform_data/ |
| H A D | i2c-gpio.h | 22 * Therefore disable open-drain.
27 * Therefore disable open-drain.
|
| /linux/tools/power/cpupower/man/ |
| H A D | cpupower-monitor.1 | 90 left. Therefore there can be some inaccuracy when cores are in an idle
126 The registers are accessed via PCI and therefore can still be read out while
133 Therefore this counter can be used to verify whether the graphics' driver
|
| /linux/Documentation/driver-api/ |
| H A D | vfio-pci-device-specific-driver-acceptance.rst | 13 sustainable. The vfio-pci driver has therefore split out
26 New driver submissions are therefore requested to have approval via
|
| /linux/tools/arch/sparc/include/asm/ |
| H A D | barrier_64.h | 10 * Therefore, if interrupts are disabled, the chip can hang forever.
24 * The branch has to be mispredicted for the bug to occur. Therefore, we put
|
| /linux/arch/sparc/include/asm/ |
| H A D | barrier_64.h | 8 * Therefore, if interrupts are disabled, the chip can hang forever.
22 * The branch has to be mispredicted for the bug to occur. Therefore, we put
|
| /linux/Documentation/ABI/testing/ |
| H A D | sysfs-bus-surface_aggregator-tabletsw | 29 New states may be introduced with new hardware. Users therefore
55 New states may be introduced with new hardware. Users therefore
|
| /linux/arch/arm64/boot/dts/rockchip/ |
| H A D | rk3588-jaguar-pre-ict-tester.dtso | 83 * issue. Therefore, let's enforce a pull-up (which is
105 * default bias is pull-down therefore being LOW. So
117 * GPIO3_C6 default bias is pull-up therefore being HIGH
|
| /linux/drivers/gpu/drm/i915/gt/uc/ |
| H A D | intel_gsc_uc.c | 46 * service path. Therefore, it is easier for us to load HuC in gsc_work()
159 * The FW might therefore try to access memory for its suspend operation in gsc_allocate_and_map_vma()
163 * The driver must therefore avoid this situation and the recommended in gsc_allocate_and_map_vma()
290 * therefore we want to make sure that the default state init completes in intel_gsc_uc_resume()
|
| /linux/Documentation/ |
| H A D | atomic_t.txt | 67 Therefore, an explicitly unsigned variant of the atomic ops is strictly
84 smp_store_release() respectively. Therefore, if you find yourself only using
143 reversible. Bitops are irreversible and therefore the modified value
184 subsequent. Therefore a fully ordered primitive is like having an smp_mb()
|
| /linux/Documentation/RCU/ |
| H A D | UP.rst | 46 Therefore, in this case, allowing call_rcu() to immediately invoke
118 list, and is therefore within an RCU read-side critical section.
119 Therefore, the called function has been invoked within an RCU
|
| /linux/include/linux/mtd/ |
| H A D | xip.h | 27 * obviously not be running from flash. The __xipram is therefore marking
70 #warning "your system will therefore be unresponsive when writing or erasing flash"
|
| /linux/drivers/scsi/pcmcia/ |
| H A D | nsp_message.c | 21 * therefore we should poll the scsi phase here to catch in nsp_message_in()
62 * therefore we should poll the scsi phase here to catch in nsp_message_out()
|